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FOREWORD 

I am delighted to be able to 
introduce this special series of 
articles on managed recorded 
information services. 

Customers are the stimulus 
behind the establishment of 
BT’s managed service and 
will continue to be the driving 
force. BT has drawn on its re¬ 
sources from all work areas to 
develop the technology and 
the quality service manage¬ 
ment required to respond 
quickly to its customers and 
provide a world-class service. 

BT is committed to continuous improvement and, as a result 
of its past successes, is investing in advanced service features 
to ensure the future growth of network managed services. 
Managed services provide two key benefits. Firstly, they 
provide major users with the flexibility to ensure that as many 
of their calls as is practicable get answered, improving their 
customer service and business results, and of course BT’s at 
the same time. Secondly, they allow businesses to try new 
ways of interfacing with their customers as they become 
available. In this respect, I look forward to the development 
of the first PSTN fax and video managed services and then 
ISDN and broadband-based multi-media managed service. 

This project has involved all parts of BT and has been an 
excellent example of one-team working, which has been 
further demonstrated in this valuable series of articles. 


ANDY GREEN 

Director Public Communications Products 
BT Products and Services 
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The managed recorded infor¬ 
mation services project has 
delivered a new platform that 
has re-focused and brought up 
to date BT’s capability for de¬ 
livering managed information 
services to customers. 

The development capa¬ 
bility within BT Development 
and Procurement has been 
able to contribute significantly 
through the development of 
innovative products such as 
interactive services distribu¬ 
tion equipment and the auxil¬ 
iary switch, to provide a unique capability for BT. These 
developments have ensured that BT is well positioned to meet 
customer needs, both in providing advanced service features 
to the information service providers and to the calling cus¬ 
tomer, and in efficiently delivering calls to the services 
through the network. 

The managed recorded information services platform has 
only recently been established and is already successful in the 
market-place. It will be the subject of further innovation and 
improvements as BT seeks to strengthen its position in the 
face of increasing competition. 


ALAN RUDGE 

Managing Director 

BT Development and Procurement 
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The Need for BT’s Managed Recorded Information Services 

PETER SHAWt, JOAN STEWARTt, and NIGEL CRISP* * 


The managed provision of recorded information sendees, although well established, is one which has 
seen much change over the years, both in its market and in its realisation. This article shows how in recent 
years these services have evolved at an ever increasing rate to match customer expectations within the 
fast changing telephony environment. The current product offerings are considered in the article, relating 
these to customer requirements and the specialised network infrastructure. 


INTRODUCTION 

The British Post Office, and later BT, has pro¬ 
vided recorded information services from within 
the telephony network for over 50 years. The 
principle of this managed provision, although 
well established, is one which in detail has shown 
much change over the years in order to match 
customer needs. 

The managed form of service is known as 
managed recorded information services (MRIS) 
and has taken an enhanced profile in recent years 
with the establishment of a particular type of 
customer who has information to distribute. In the 
managed arena, this customer, usually referred to 
as the service provider , puts information into the 
network and BT automatically makes it available 
to a large number of calling customers. Informa¬ 
tion that can be distributed in this way can be vast 
ranging and apply to the commercial, sporting, 
entertainment and retail markets. 

MRIS also provides a facility for other parts of 
BT’s business wherever there is a need to give 
customers information on such topics as network 
conditions. Providing information in this way can 
significantly enhance the company image, by 
keeping the customer informed, helping when in 
difficulty and generally providing a caring ser¬ 
vice. 

INFLUENCING FACTORS 

The need for MRIS relates to being in a position 
to provide BT users and service providers with 
features and facilities which enable the calling 
customer to access a vast wealth of information. 
The realisation of a product to meet these needs 
has been determined by a number of influencing 
factors: 

• information market, 

• growth potential, 

• BT network announcements, 

• technology, and 

• history. 


t BT Product and Services Management 

* BT Development and Procurement 


Information Market 

The growth of the information market, commonly 
known as Andiotex, has accelerated as a result of 
the change to the UK telecommunications opera¬ 
ting conditions and the ability to charge calling 
customers’ calls at a premium rate. 

Growth Potential 

Continued growth in applications indicates that 
the facilities offered today have not yet reached 
an end-point; there is potential for many more 
applications and service enhancements. Con¬ 
fidence in this relates to recent growth in the 
product offering. As an example, the established 
MRIS product is based on the principle of passing 
information in one direction. This is currently 
being enhanced to provide the capability to inter¬ 
act with the customer. The principle promises 
considerable potential for growth. 

BT Network Announcements 

As the general public’s awareness of quality in¬ 
creases, fed by continued network modernisation 
and improvement, informative and friendly net¬ 
work announcements come to be expected. This 
will undoubtedly enhance everyone’s confidence 
in BT. 

Technology 

Developments in the information technology in¬ 
dustry have been a significant enabling factor in 
the fulfilment of Audiotex applications, because 
without that technology the applications could 
not have been realised to the level that they 
have. The technology has progressed to a point 
which enables BT to respond quickly to cus¬ 
tomer needs. 

History 

In the current environment, the historical back¬ 
ground is by no means the strongest influence, but 
certainly is not an insignificant factor, because of 
the long establishment and acceptance of re¬ 
corded information services by the public. 
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HISTORY OF MANAGED SERVICES 

In 1936, the speaking clock was introduced and 
provided the first managed recorded information 
service for the general calling public. In 1956, the 
weather forecast service was launched, and this 
was quickly followed by cricket, road and tourist 
information services. These services became col¬ 
lectively known as Guidelines and were priced at 
standard local charges. The information pro¬ 
viders , such as the Meterological Office or Tourist 
Board, were paid a percentage of the call revenue 
earned, based on a fixed unit fee per call. By 1986, 
BT’s Guidelines were generating in excess of 400 
million calls per year. 

Although these services were popular, they 
were not regarded as profitable. Under the terms 
of its operating licence, BT could not cross-sub- 
sidise the payments for the information with the 
revenue earned from the transportation of the call. 
Demand was also increasing from businesses and 
entrepreneurs who wanted to provide information 
services similar to Guidelines, but with added 
value and added features. 

The managed business has now changed, and 
of the original Guideline services Timeline is the 
only survivor, being regarded as an exception 
because of sponsoring arrangements. In many 
ways, this service is seen as a national institution. 

Premium Rate Services in the UK 

To adhere to the licence and to satisfy the growing 
added-value need, national premium rate ser¬ 
vices were introduced in April 1986, the concept 
of which can be described as a partnership be¬ 
tween BT, who provides the network and the 
technical capability, and a third party (service 
provider), who provides a service to the calling 
customers. Callers to premium rate services are 
charged at a premium rate; that is, a rate above 
BT’s normal call charges. This premium is then 
passed on to the service provider. 

Currently, two national number access codes 
are used for premium rate services: 0891 and 
0898. Both have identical charging arrangements 
to the calling customer and give the same revenue 
share to the service provider. The two codes are 
differentiated by the types of information allowed 
on each. 

Premium Rate Services Worldwide 

BT led the world with the introduction of national 
premium rate services when it launched its ser¬ 
vice in 1986, two years in advance of the com¬ 
parable service in the USA. European countries 
have followed and are now in various stages of 
progress. Currently, BT has the largest premium 
rate service in Europe in terms of numbers of lines 
and calls. 

CALLSTREAM CALL SERVICE 

Callstream is the commercial name for BT’s na¬ 
tional premium rate services and encompasses the 


means of transporting and terminating calls. 
There are two methods of call termination within 
Callstream services: 

• independent; and 
% managed. 

Independent Callstream Facility 

Under this option, service providers have calls 
delivered to their premises via lines connected to 
the BT network. The service providers then have 
their own answering capability on their premises 
and, by using this capability, provide information 
services. 

The independent service is most suitable for 
service providers with complex and highly spe¬ 
cialised applications. However, this type of ser¬ 
vice is costly to set up and requires expertise to 
maintain and operate. Also, keeping up to date 
with developing features and facilities can be a 
costly overhead. 

Callstream Managed 

The managed service provides the service pro¬ 
vider with a total product package: the service is 
run on BT lines and equipment is installed on BT 
premises. The service provider has only to pro¬ 
vide the audio information. 

The advantages of managed service are: 

Q calls are answered on high-quality, reliable 
answering equipment, which is sited within the 
telephony network; 

© it enables the service providers to focus on 
promoting and marketing their information; 

© the service provider is released from the capi¬ 
tal outlay associated with the provision and instal¬ 
lation of the independent service; 

© the service provider does not need expertise in 
the maintenance and operation of complex tele¬ 
phony equipment; 

® BT provides the telephony aspects of service 
administration by monitoring the call volumes 
and configuring the equipment to cope with de¬ 
mand; and 

€> it can provide additional capacity to inde¬ 
pendent service providers as and when required. 

Other Managed Applications 

The ability to charge calling customers at a pre¬ 
mium rate has been instrumental in setting up the 
current MRIS infrastructure. However, once MRIS 
was realised, the ability to provide capacity, econ¬ 
omically, for BT products other than Callstream 
became viable. Therefore, LinkLine™ services 
(using 0800 and 0345 codes) and public switched 
telephone network (PSTN) services have made 
good use of MRIS. As an example, the mammoth 
task of providing PSTN change-number an¬ 
nouncements for the recent London code change 
was an easy one for MRIS. 
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MRIS MARKET 

The overall market requirements are generally 
derived by working closely with service pro¬ 
viders, to assess and understand their real needs. 
Indeed, recent experience has shown this to be 
highly effective. From the identified market re¬ 
quirements the resulting MRIS product offerings 
are derived, having taken into account the in¬ 
fluencing factors previously discussed. 

Identified Market Requirements 

The following market requirements, drawn both 
from internal BT and from external customers, 
have been identified and are currently being sat¬ 
isfied or realised: 

® services which start at the beginning of the 
message, 

# direct update of announcement services, 

% high-call-volume answering, 

# real-time call statistics, 

© live service, 

# fast delivery, 

® interaction with the calling customer, 

# information capture, and 
0 full BT call management. 

Start-at-the-Beginning Messages 

Messages and services which are provided stall¬ 
ing at the beginning are now generally demanded 
by calling customers, most of whom are paying 
at a premium rate and expect a high quality of 
service. 

Direct Update of Announcement Services 

Those service providers who supply up-to-the- 
minute ‘fresh’ information need to gain direct 
access to their services and update messages im¬ 
mediately. 

High-Call-Volume Answering 

Services which are promoted by the high-volume 
media, such as television and radio, can generate 
high call volumes over a relatively short period of 
time. MRIS therefore needs to handle these calls 
in a manner that achieves the highest possible call 
answering rate. 

Real-Time Call Statistics 

Service providers promoting services in the daily 
or short-term market need to assess the effective¬ 
ness of their advertising to allow them to take 
action to maximise their revenue. Therefore, ac¬ 
cess to real-time call statistics is essential. Also, 
televote applications used by television and radio 
need their calling figures available in this manner 
to feed back results to their viewers and listeners. 

Live Service 

Many service providers, particularly in the sport¬ 
ing market, need to be able to give live commen¬ 


tary on events and hence need a broadcast, or live 
feed , facility. 

Fast Delivery 

Service providers can often demand the fast pro¬ 
vision of services to meet specific market niches 
that become evident on short time-scales or to 
meet emergency situations. 

Interaction with Calling Customer 

Once a call is established, the most convenient 
method for the calling customer to request 
multiple choice information is by interaction 
using voice or TouchTone™. 

Information Capture 

Service providers, for example, in the retail mar¬ 
ket, generally want to take orders; hence the 
ability to capture information from the calling 
customer is a prime need. 

Full BT Call Management 

It has been recognised by the market that the 
lines-based service requires the service provider 
to administer call management by the purchase of 
additional lines. This has led to inefficiencies in 
call completions, but full call management by BT 
has overcome these difficulties by using MRIS 
and the network infrastructure 1 . 

Current Product Offering 

Based upon the market requirements, the follow¬ 
ing product offerings are available: 

• Callstream Managed service; 

• Callstream Enhanced Managed service; 

• LinkLine MultiLink; and 

• network announcement services. 

This is an evolving product range and future 
product enhancements are discussed in a later 
article 2 . 

Callstream Managed Service 

This product was launched in late-1986 to address 
smaller businesses looking for an entry into the 
premium services market. The current service 
incorporates the following features: 

• Calling customers can listen to start-at-the-be- 
ginning messages, which last a maximum of two 
plays after which the call is automatically discon¬ 
nected. 

• The service providers can update their service 
by cassette tapes, which they supply to BT. This 
is ideal for studio-quality recorded an¬ 
nouncements, which often combine speech and 
music. 

• The service providers can directly update their 
messages via the telephone network free of 
charge. This is commonly known as remote up¬ 
date and is ideal for frequently updated an¬ 
nouncements, such as news bulletins. 
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• Call status reports are dispatched weekly to the 
service providers and provide a day-by-day ana¬ 
lysis of the number of calls received and the 
associated revenue for each active service num¬ 
ber. 

® Charges are based around rental of lines in 
blocks of ten. 

Identified market requirements not currently 
addressed by this product are scheduled to be 
incorporated in the summer of 1992 2 . 

Callstream Enhanced Managed Service 

Enhanced Managed is the latest addition to the 
Callstream portfolio introduced in May 1991. It 
was designed for those occasions when service 
providers need to run a high-volume campaign 
requiring full call management, such as a televote 
or a television advertised service, and is also ideal 
for information services with a wide appeal such 
as live commentaries. 

This service incorporates the following fea¬ 
tures: 

® Messages can be updated by cassette tape and 
remote update. 

@ The facility of providing live services such as 
horse racing commentaries is made possible by 
using one of two methods: dialling over the tele¬ 
phone network or direct connection from the ser¬ 
vice provider’s premises. 

• Weekly status reports are provided. 

® Real-time statistics are available by using a 
TouchTone telephone. This information is up¬ 
dated every 1 minute or 15 minutes and the call 
counts can be reset to zero at any time. 

Real-time statistics can also be accessed di¬ 
rectly by using a modem and personal computer 
to provide a more detailed analysis on each ser¬ 
vice. 

• Charges are based around the rental of individ¬ 
ual services; that is, one announcement. 

• Full call management. 

Two identified products are available within 
the Enhanced Managed service: Broadcast and 
Televote: 

• Broadcast announcements may be start-at-the- 
beginning and can be updated by tape or remote 
update. The facility of giving live commentaries 
on events is available. Some examples of broad¬ 
cast services are racing commentary, competition 
lines and information lines. Broadcast services 
can be rented on a weekly, monthly, quarterly or 
annual basis. 

• Televote announcements are short duration, 
non-start-at-the-beginning announcements and 
can be updated by tape or remote update. Televote 
announcements are primarily used for voting via 
the telephone network, but can be used whenever 
a very short announcement is required. Televote 
services can be rented on a daily, weekly, month¬ 
ly, quarterly or annual basis. 


LinkLine MultiLink 

This product was launched in the summer of 
1987 and modified in late-1990. It satisfies the 
LinkLine demand for campaign style, free and 
local-charge-rate promotions. The current ser¬ 
vice incorporates the ability to update messages 
by cassette tape and offers full call management 
to the service provider. Identified market re¬ 
quirements not currently addressed by this pro¬ 
duct are scheduled to be incorporated in 
summer-1992 2 . 

Network Announcement Services 

This service is available via network operations 3 
and is aimed at network planners and operators 
requiring network emergency announcements or 
changed-number announcements. It incorporates 
the following features: 

• start-at-the-beginning announcements to the 
calling customer, which may be charged or not 
charged; 

• remote update or tape; 

% fast delivery; 

• full call management, high or low call volume; 
and 

• statistics on the number of calls. 


CONCLUSION 

Working closely with external and internal custo¬ 
mers to identify and understand their needs and 
then matching these to BT’s operating strategy is 
enabling MRIS products to be aligned precisely 
with the identified market requirements. The in¬ 
frastructure itself is future-proofed to allow new 
services to be realised quickly and efficiently with 
advanced features and facilities. Value has been 
added to the managed product which realises 
BT’s quality and style and satisfies fully the needs 
of the customer. 

The MRIS platform as it is today grew out of 
the above elements and from public demand for 
information services. It is an extremely successful 
market and BT as a company is constantly explor¬ 
ing and refining markets in which to expand its 
expertise. MRIS enables service providers to be 
divorced from having to concern themselves with 
decisions regarding their telecommunications in¬ 
frastructure and capacity maintenance. 
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Glossary of Abbreviations Used in this Issue 

ASCP 

Auxiliary switch call point 

NU 

Number unobtainable 

AS/MM1 

Auxiliary switch man-machine interface 

OPRA 

Opinion poll registration application 

BMIS 

Basic managed interactive service 

OSMU 

OPRA system management unit 

CAF 

Caller audio file 

PC 

Personal computer 

CFEP 

Caesar front-end processor 

PCM 

Pulse-code modulation 

COU 

Central operations unit 

PIN 

Personal identification number 

CPU 

Central processing unit 

PMUX 

Primary-order multiplexer 

DDI 

Direct dial-in 

PSTN 

Public switched telephone network 

DMSU 

Digital main switching unit 

RAC 

Recorded announcement centre 

DSN 

Derived services network 

RAM 

Random-access memory 

DTMF 

Dual-tone multi-frequency 

RDL 

Remote download 

DULF 

Dial-up live feed 

RIDE 

Recorded information distribution equipment 

EPROM 

Erasable programmable read-only memory 

RISCP 

Recorded information services control processor 

FRP 

Fault reporting point 

RUD 

Remote update 

ICSTIS 

Independent Committee for the Supervision of 

SAB 

Start-at-the-beginning 


Standards of Telephone Information Services 

SABRE 

Start-at-the-beginning registration equipment 

LAN 

Local area network 

SMU 

System management unit 

MAU 

Monitor alarm unit 

SPAF 

Service provider’s audio file 

MMI 

Man-machine interface 

SSG 

Start-stop generator 

MRIS 

Managed recorded information services 

VDU 

Visual display unit 

NAC 

National announcement centre 

VSE 

Voice services equipment 

NMC 

Network management centre 

WAN 

Wide area network 

NNG 

National number group 

WN 

Worldwide Networks 

NPG 

Network Planning Guide 
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Managed Recorded Information Services—An Overview 

JOHN SHEPHERD, and KEVIN BOSHERt 


This article begins by tracing the history of the managed recorded in formation services (MRIS) and the 
development of the equipment to the present state of the art. It leads into an overview of the architecture 
of the network system, together with a summary of the operation of MRIS. 


INTRODUCTION 

This article gives an overview of the systems and 
equipment used to provide BT’s managed re¬ 
corded information services (MRIS), giving em¬ 
phasis to the technology and techniques used. It 
begins with a brief account of the history of 
recorded information services, which leads into 
a description of the core equipment and service 
forms now provided. 

In setting the scene this way, the reader is 
guided into the other articles in this Journal , 
which describe the equipment and services in 
greater detail. 


MANAGED SERVICE 

The first product offering for a managed recorded 
information service comprised a basic an¬ 
nouncement service with tape-only update. This 
has been supplemented by more advanced ser¬ 
vices, as more-enhanced equipment has become 
available to give a greater degree of customer 
control; for example, in high-volume televotes, 
remote update of announcements, interactive ser¬ 
vices and call statistics. 

The fundamental factor identifying a man¬ 
aged service from an independent service is that, 

Figure 1 

Network positioning ——- 

of MRIS equipment f BT Worldwide Networks 



for a managed service, the voice equipment, in 
all its forms, is within the telephony network and 
installed on BT premises. The information 
loaded is normally provided from non-BT sour¬ 
ces by service providers. 

The First Fifty Years 

The use of recorded information services in the 
telephony network is not a new concept; notably, 
the first service of this sort was the speaking 
clock, originally introduced in London in 1936 
and expanded nationally in 1942. Throughout its 
history, this service has been provided by spe¬ 
cialised equipment which has stored the informa¬ 
tion by using optical discs, magnetic tape drums 
and, currently, solid-state semiconductor stores. 

From the 1950s onwards, more general infor¬ 
mation services were developed which 30 years 
later formed a portfolio of ‘Guideline’ services, 
giving information on subjects such as cricket 
matches, weather and road traffic. The technol¬ 
ogy used was magnetic tape and drum stores, in 
the form of the British Post Office Equipment 
Announcer Numbers 9 and 11. The services were 
charged at local call rate, and generally the be¬ 
ginning of the announcements did not coincide 
with the start of the call. 

The first 50 years of recorded information 
services has been described in a previous issue of 
the Journal' , and in many ways this current issue 
forms a continuation of the story, which has now 
been enabled by the extensive use of new and 
sophisticated technology. 

Derived Services Network 

Flexibility in charging requirements for calls has 
been made possible by a national overlay network, 
known as the derived sendees network (DSN). 
This has been fundamental in allowing calls to be 
charged at rates above the normal trunk rate, and 
thereby enabling MRIS to be viable. Access to the 
overlay network is determined by the calling cus¬ 
tomer dialling non-geographical national number 
group codes, such as 0800, 0345,0898 and 0891, 
from the public switched telephone network. 

The DSN originally used analogue switches 2 , 
but is now entirely digital 3 . The network is formed 
from eight switching nodes, each of which now has 
associated with it a recorded announcement centre 
(RAC), which provides a gateway for connecting 
to the managed information services. See Figure 1. 
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An Early Managed Facility 

A BT product, the mass answering facility, en¬ 
abled customers to conduct televotes by using the 
analogue DSN. This used amplifier circuits to 
provide 500-circuit access to announcements na¬ 
tionally. It was known within BT as the Roland 
Rat service, since the first service it carried was 
for a national television Roland Rat phone-in. 
The service was expanded by using CEPTEL 
equipment to provide a live-feed capability and a 
total of 1280 lines capacity nationwide, which 
was split into two units known as Kevin and Eml, 
each of 640 lines. This has since been replaced 
by the recorded information distribution equip¬ 
ment (RIDE) 4 . 

ANNOUNCEMENT CENTRES 

To widen the attraction of the service, the first 
RAC was opened in 1986 in London. It consisted 
of three items of announcement equipment, known 
as the first-generation voice services equipment 
(VSE1). This enabled lower volumes of calls to be 
connected economically to announcements, and 
was directly linked into the DSN switch. 

The RAC was in service for only three months 
before demand created a need to expand the 
equipment room. The growth continued with two 
new RACs at Birmingham and Leeds, eventually 
leading, by 1988/1989, to the current eight sites, 
(as before, plus Glasgow, Guildford, Cambridge, 
Manchester and Bristol), and the establishment 
of a national announcement centre (NAC) at 


Oswestry for central control and statistics collec¬ 
tion. This provided the flexibility needed for BT 
to produce a fast response to customers’ (service 
providers’) changing needs. 

Call Access 

For services operating on RAC-based equipment, 
the announcements are provided at specific 
RACs, with calls to the announcement service 
networked across interconnecting routes on the 
DSN. For services generating higher volumes of 
calls, the announcements are distributed by the 
RIDE system, with calls terminating at the RAC 
collocated with the point-of-entry to the DSN. 
This arrangement avoids congestion of the DSN 
interconnecting routes. 

RIDEs are also connected directly to digital 
main switching units (DMSUs) (see Figure 1), 
and these were used recently to provide an¬ 
nouncements for the London code change, with 
calls to these being routed directly to the RIDE 
corresponding to the DMSU to which the call is 
sent. Future uses of the DMSU RIDEs will in¬ 
clude Timeline, high-volume televotes and na¬ 
tional code change announcements (for which 
they are currently being upgraded). 

RECORDED ANNOUNCEMENT 
CENTRES 

Each RAC consists of two areas: the equipment 
area, providing an air-conditioned room for the 
MRIS hardware; and the operations area contain- 



NAC: National announcement centre VSE: Voice services equipment 
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Figure 3—NAC operation room 
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Figure 4—NAC configuration 


ing the application control terminals. A typical 
RAC configuration is shown in Figure 2. 

Voice services are primarily sourced from the 
VSE 5 . Initially, VSEs were connected directly to 
the DSN, but to increase flexibility and to help 
overcome the problem of call volume fluctua¬ 
tions, an auxiliary switch was introduced be¬ 
tween the VSE and DSN. 

Typically, low to medium call volumes to an¬ 
nouncements terminate on the VSEs, routing 
through the auxiliary switch, which determines the 
appropriate announcement and hence destination 
VSE. The auxiliary switch and VSE are controlled 
by their own control PCs, with management and 
call statistics being collected from the auxiliary 
switch via the auxiliary switch call point (ASCP). 
Access to the management statistics is from the 
local statistics processor. Service provider access 
to call statistics is from the auxiliary switch opi¬ 
nion poll registration application (OPRA) 6 proces¬ 
sor located at the NAC, which is connected to the 
ASCP via the communications network 7 . 

High call volumes to announcements are con¬ 
nected to the RIDE and terminate on the appro¬ 
priate announcement within the RIDE switch, the 
announcement being sourced from the NAC at 
Oswestry. 

The RIDEs are remotely controlled from the 
NAC by the recorded information services con¬ 
trol processor (RISCP). This also collects call 
statistics from the RIDEs, with service providers 
receiving their call statistics from the OPRA pro¬ 
cessor located at the NAC. 

NATIONAL ANNOUNCEMENT CENTRE 

The NAC at Oswestry, see Figure 3, is the focal 
point for MRIS. It currently houses equipment for: 

• announcement generation and the insertion of 
‘live feeds’ on the DSN RIDE network; 

• start-stop message generation for ‘start-at- 
the-beginning’ (SAB) announcements on the 
DSN RIDE network; 

• distribution of information/announcements to 
the RACs; 

• collection of call statistics from the DSN 
RIDE network and auxiliary switch installations; 

• control of the DSN RIDE network; and 

• recording units needed for regulatory pur¬ 
poses to monitor announcements supplied by 
service providers. 

The configuration of the equipment in the 
NAC is shown in Figure 4. 

MRIS EQUIPMENT 

The eight RACs and the NAC contain MRIS 
equipment as described in the following sections: 

Voice Services Equipment (VSE) 

VSE is call terminating equipment which provides 
access to stored announcements, with the ability to 
answer 30 simultaneous incoming calls. The an¬ 
nouncements themselves are stored digitally on 
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internal hard discs. The dialled digits received 
determine the announcements played to the caller. 

The basic VSE1 includes the following fa¬ 
cilities: 

• VDU control; 

• announcements loaded from tape; and 
® low announcement storage capacity. 

The advanced generations of VSEs 
(VSE2/VSE3) provide the following: 

© PC control; 

• announcements loaded from tape or remotely 
updated; 

© high announcement storage capacity; 

© analogue connections in the case of VSE2 and 
digital connections in the case of VSE3; 

• advanced features, such as the interactive ser¬ 
vice, and dial-up live feed; and 

• remote access and control. 


The auxiliary switch has the capacity for 30 x 
2 Mbit/s terminations and can switch any incom¬ 
ing channel to any outgoing channel. It can pro¬ 
vide a concentration point when using the 
wait-on-start facility to allow several calls to a 
common announcement to be held for a short 
period (or until a set number has accumulated or 
a set time elapsed), before all calls are passed 
down the same channel for connection to the 
announcement in a ‘start-at-the-beginning’ man¬ 
ner. This maximises the use of the VSE channels. 

The auxiliary switch has a translation capac¬ 
ity which enables up to six digits to be accepted 
and a maximum of 10 digits to be passed forward 
with the call. Currently on MRIS, four digits in 
and two digits out are being used. 

Recorded Information Distribution 
Equipment (RIDE ) 4 


As the VSEs have developed, their physical size 
has decreased, which has allowed more effective 
use of the available accommodation. For example, 
a VSE1 in a single cabinet provides 30 channels of 
service, whereas four VSE3 units in a similar 
single cabinet provide 120 channels of sendee. 

Auxiliary Switch 5 

The auxiliary switch comprises three modules 
and a controlling PC. Each module is a secure 
non-blocking bidirectional 300-channel digital 
switch (ten groups of 30 channels). It is possible 
to allow a call to arrive on one module of the 
auxiliary switch and to be passed to another, as 
all three are interconnected by a 64-channel ring 
of intermodule links. 


The RIDE is a totally non-blocking switch, tar¬ 
geting a maximum of 720 simultaneous calls to 
any one of a maximum of 120 announcements. 
Announcement distribution and control for RIDE 
is centred on the NAC for a fast response to 
announcement changes and statistics provision. 

The DSN RIDE network (see Figure 5) pro¬ 
vides a total answering capacity of 6480 lines to 
120 duplicated announcements (consisting of 
live feed, SAB and non-SAB services). Nine 
RIDE switches are installed, one in each RAC 
except London, which includes two. 

Announcements 

Announcements are distributed from the NAC 
over 2 Mbit/s rings. Both the transmit and receive 



RIDE RING 
MONITORS 


NAC [ RAC 


DSN: Derived services network 
NAC: National announcement centre 
PMUX: Primary-order multiplexer 
RAC: Recorded announcement centre 


RIDE: Recorded information distribution equipment 
SABRE: Start-at-the-beginning registration equipment 
SSG: Start-stop generator 
VSE: Voice services equipment 
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paths are used to provide 60 channels per 
2 Mbit/s system. Four rings are used to provide 
120 duplicated announcements, diversely routed 
for security. 

SAB announcements are fed from the VSE3 
via the start-stop generator (SSG) 4 , which pro¬ 
vides announcements with start and stop signals. 
The signals are detected by start-at-the-begin- 
ning registration equipment (SABRE) 4 con¬ 
nected to each RIDE switch, which stores the 
announcements. Incoming calls are connected to 
the announcement within the SABRE. 

Non-SAB announcements are fed via the 
VSE2 to the RIDE ring and are played continu¬ 
ously. Incoming calls are connected directly to 
the ring announcement by the RIDE. 

Private wire live feeds are connected to the 
rings, as are other non-SAB services, via the 
PMUX. Ring returns are passed through a 
PMUX and monitor alarm unit (MAU) 7 , which 
checks for the presence of an audio signal and 
generates an alarm if the signal is not detected 
after a preset period of time. 

Control 

The DSN RIDE network is controlled centrally 
from the NAC by using the RISCP, which is 
connected to each RIDE via a dedicated Kilo- 
Stream link. The RISCP also collects RIDE call 
statistics and passes these to the OPRA. 


are provided at the NAC, and these centrally 
collect and collate call-statistic information from 
the DSN RIDE and auxiliary switches (via the 
RISCP and ASCP respectively). 

The OPRA provides three statistics services, 
presented on a DSN regional basis: 

• Detailed Totals of calls and call holding 
times at 15 minute intervals. 

• Summary Call totals only, at 15 minute in¬ 
tervals. 

• I minute Call totals only, at 1 minute inter¬ 
vals, available for RIDE statistics only. 

Service providers can access and collect these 
statistics by using a PC and modem via a dial¬ 
up/di al-back process, or a TouchTone™ tele¬ 
phone (CFEP access), where the call statistics are 
converted into speech messages. 

NAC-RAC Communications Network 7 

The communications network (see Figure 6), 
comprising 2 Mbit/s links, has been installed to 
enable duplicate live-feed connections to be pro¬ 
vided quickly to the RIDE. This speeds up pro¬ 
vision and reduces costs for service providers, 
since the only private wire needed is that from 
the service provider to the RAC. 

From the RAC, the live feed announcement is 
sent direct to the NAC, with a security route 
provided via the paired RAC. 


Figure 6 
NAC-RAC 
communications 
network 


Opinion Poll Registration Application 
(OPRA ) 6 

Two OPRA systems (comprising an OPRA pro¬ 
cessor and Caesar front-end processors (CFEPs)) 



NAC: Network announcement centre RAC: Recorded announcement centre 


SYNCHRONISATION 

All the digital MRIS equipment is synchronised 
from the main network. 

Two diversely routed KiloStream circuits termi¬ 
nating on synchronisation equipment provide the 
synchronisation source for the NAC. This equip¬ 
ment detects failure of the main feed, and switches 
automatically to the security feed. Links from the 
distribution equipment supply the RIDE rings, from 
which the RIDE switches derive their timing. 

The RAC equipment not connected to the RIDE 
rings (for example the auxiliary switches) derive 
their timing from the master clock, via the DSN 
exchange. This arrangement is shown in Figure 7. 

FURTHER DEVELOPMENTS 

A number of developments are in progress and 
these are described below: 

RIDE on Digital Main Switching Units 4 

The RIDEs were initially installed on digital main 
switching units (DMSUs) to provide courtesy an¬ 
nouncements for the London code change, with 
announcements being provided internally by 
RIDE. They are currently being enhanced and 
expanded for the national code change, Timeline, 
and high-volume televote applications by being 
connected to centrally generated announcements 
provided by a further set of RIDE rings. 

Because of the number of DMSU RIDE units 
(at present 65), the distribution network will be 
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ACE: Automatic cross-connection equipment 
DMSU: Digital main switching unit 


DSN: Derived services network 
RIDE: Recorded information distributon equipment 


Figure 7 

Synchronisation of 
MRIS equipment 


configured as three sets of rings serving RIDE 
switches in three geographical zones (see Figure 8). 

The DMSU RIDE network will have its own 
OPRA, with the same facilities provided for the 
DSN RIDE OPRA. Control is via seven RISCPs 
at the NAC, but these will be integrated by the 
RIDE system management unit (SMU) develop¬ 
ment in the future (see Figure 9). 

RAC Monitor Alarm Unit 7 

Installation of MAUs within each RAC will enable 
all RAC equipment alarms to be extended to the 
NAC. This arrangement will provide centralised 
visibility of the status of all MRIS equipment. 

RIDE System Management Unit (SMU ) 7 

The RIDE SMU consolidates the control termi¬ 
nals required by the DSN and DMSU RIDEs, by 
interfacing the eight RISCPs to a pair of work 
stations which provide the operator with a com¬ 
mon window-based management system. 



Enhanced NAC-RAC Communications 
Network 7 

The introduction of the auxiliary switch OPRA 
created the need to transmit large amounts of data 
between the RACs and the NAC. The existing 
KiloStream links were unable to handle this, and 
so a new strategy was undertaken to create an 
RAC local area network and connect this to the 
NAC local area network via the communications 
network, effectively creating a wide area network 
(see Figure 10). The enhancements to the com¬ 
munications network to do this involve replacing 
the PMUXs with intelligent network multiplex¬ 
ers, which have a variety of interfaces (X.21, 
analogue 2-to-4 wire and 2 Mbit/s) and provide 
centralised control and route creation. 


The wide area network creates a secure plat- Figure 8 

form (with automatic rerouting upon link DMSU RIDE loop 

failure), which can quickly and easily accommo- configuration 
date growth and new service equipment. 
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Sourcing Voice Services 

Voice Services Equipment, Auxiliary Switch and Voice Applications 

NIGEL CRISPt 


The prime source of voice services in the managed recorded information sendees (MRIS) environment 
centres on voice sendees equipment (VSE). This article describes the many aspects of VSE, from its 
capabilities and development, through to its continuing market-led enhancements. The article shows 
how the VSE is configured for MRIS and, in particular, how it is used, alongside the auxiliaiy switch, to 
provide a highly-efficient means of giving service to customers. Emphasis is placed on the sendee 
applications as perceived by the calling customer and the service provider, showing how the MRIS 
service offerings range from simple passive messages to complex generic applications and how, from an 
engineering sense, the capabilities of voice sendees continue to evolve to match the emerging require¬ 
ments of customers. 


INTRODUCTION 

Ten years ago, recorded messages in the tele¬ 
phone network were generally restricted to non- 
start-at-the-beginning announcements provided 
by mechanical tape recorder technology, as that 
was the only way to make the information avail¬ 
able at the calling capacity required. Over the 
intervening years, new technology has enabled 
the development of voice services equipment 
(VSE), which, in turn, has enabled start-at-the- 
beginning announcements as the norm, together 
with many other new features and new capa¬ 
bilities for both the calling customer and the 
service provider. In particular, highly reliable 
recognition of spoken words has recently become 
available, which can be used cost effectively in a 
multi-channel manner. 

All these developments, prompted by new 
technology, have stimulated the market for voice 
services and, in recent years, have resulted in a 
complete cultural change in the provision of 
managed message-based services. Hence man¬ 
aged recorded information services (MRIS) have 
become possible. 

This article shows how the VSE and associ¬ 
ated equipment are used to meet the needs of 
MRIS customers by providing an efficient man¬ 
aged environment to source a variety of voice 
services and applications. 

ANNOUNCEMENT CENTRES 

Figure 1 shows the VSE within the architecture 
of the announcement centres. The VSE is in¬ 
stalled in two general locations: the national an¬ 
nouncement centre (NAC) at Oswestry, and at the 
recorded announcement centres (RACs), which 
are collocated with each of the derived services 
network (DSN) switching centres. 


t BT Development and Procurement 


VSE at the RAC 

The RAC provides the gateway for directing the 
calling-customer traffic to all VSEs. 

The VSE installed in the RACs generally 
handles services taking medium-calling-rate 
traffic; the traffic is connected via a flexibility 
point, known as the auxiliaiy switch. The ser¬ 
vices provided in this manner can be interactive 
with the calling customer and can capture infor¬ 
mation left by the calling customer. The VSEs 
at the RAC also have dial-up access from the 
service provider for both updating services and 
downloading messages left by calling custo¬ 
mers; this access is controlled by special proce¬ 
dures described later in this article. Audio 
update locally from tape is also provided. Call 
statistics for provision to the service provider 
via the opinion poll registration application 
(OPRA) 1 are conveyed via the auxiliary switch 
call-point processor, and statistics for oper¬ 
ational purposes are provided by the local stat¬ 
istics processor. 

VSE at the NAC 

Some VSE is provided centrally at the NAC, with 
the services distributed to the RAC via digital 
transmission rings and connected by using re¬ 
corded information distribution equipment 
(RIDE) 2 switches. This provides a highly effec¬ 
tive means of handling traffic to the high-calling- 
rate services, but because these switches are 
unidirectional in transmission-carrying capa¬ 
bility, interactive services cannot be connected in 
this way. 

Live feeds can be provided, which effectively 
puts the VSE in a switched feed-through mode to 
allow the service provider to provide, for 
example, a commentary on a sporting event; this 
feature is described in more detail later in this 
article under the RUD/DULF procedure. 
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Figure 1 
VSE in the 
announcement 
centres 



RIDE: Recorded information distribution equipment VSE: Voice services equipment 

OPRA: Opinion poll registration application 


VOICE SERVICES EQUIPMENT (VSE) 

The VSE is the heart of voice services provision¬ 
ing for MRIS, since it is where the services are 
formulated and where the voice message infor¬ 
mation is stored. 

The basic requirements of VSE are that it 
should connect to the switched telephony net¬ 
work, answer incoming calls and play the re¬ 
corded messages starting at the beginning. The 
VSEs used for MRIS are exclusively provisioned 
as 30-channel units with each incoming channel 
operating and providing service asynchronously 
and independently of any other channel. 

The design of the VSE has relied heavily on 
computer technology for its development and 
continued evolution. In particular, high-speed 
processors, hard disc technology and high-ca¬ 
pacity solid-state storage devices have made 
highly-flexible announcement equipment 
possible. 

In the very earliest VSE, messages were se¬ 
lected purely on the channel to which the incom¬ 
ing call was connected. As the market for voice 
services grew this proved to be inefficient and 
restrictive, and now all VSE selects services on 
either two or more direct-dial-in (DDI) digits 
passed from the network; these digits usually 
correspond to the last digits of the number dialled 
by the calling customer. 

All VSEs used for MRIS are designed to work 
in a secure operational environment, operate 
from the exchange battery supply, interconnect 
with the exchange alarm scheme and comply 
with the appropriate safety and electromagnetic 
compatibility requirements. The need to keep 


service downtime at an absolute minimum is of 
high importance in choosing VSE for MRIS. 

Since the first developments of VSE in the 
early-1980s, three generations of equipment have 
become established, offering more and more 
flexibility and future-proofing to keep pace with 
the market requirements. 

First-Generation VSE 

The first-generation VSE (VSE 1) offered a basic 
message replay capability with functionality em¬ 
bedded in the main equipment software. The 
operation is simple: on connection of the call, the 
DDI digits select the message, which is then 
played a predefined number of times before the 
call is completed. Messages are always loaded 
directly to the VSE1 via a tape recorder interface. 

One of the earliest VSE1 products grew out of 
a BT-sponsored development for a voice services 
platform which was carried out during the early- 
1980s. After various developments in the emerg¬ 
ing MRIS environment, the platform became a 
product known as Talon. The architecture thus 
developed set the pattern and the principles for 
subsequent VSE design; that is, computer hard¬ 
ware with non-volatile hard disc storage using 
dual main/stand-by format, which is controlled 
by a processor handling 30 channels of service 
simultaneously. The Talon VSE1 connects via 
2048 kbit/s bearers, uses 2-digit DDI to select 
from 100 services, can store up to 250 messages 
and has storage space for up to 4 hours of audio 
information. 

When the VSE Is were first installed, they 
were connected directly to the main network 
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switch and only later were the auxiliary switches 
connected in between to give an added dimension 
of flexibility. 

Second-Generation VSE 

The main restriction of the VSE1 is that its func¬ 
tionality is embedded in the software. This means 
that, although the content of the recorded mess¬ 
age can change, the form of the service is fixed 
and cannot be changed or altered without major 
development by the VSE manufacturer. With the 
second-generation VSE (VSE2), while the equip¬ 
ment actually has no service functionality in¬ 
itially, users can define and install services of 
their own form and functionality. This is 
achieved by the use of a service definition lan¬ 
guage, which enables the user to produce high- 
level application software to extend the simple 
replay-message type of service in a number of 
ways including: 

# controlling the number of message replays; 

# constructing the services in a multi-message 
format; 

# generating specialised statistics; 

# recognising audio signals and activity from 
the calling customer; and 

© selecting messages from a portfolio. 

The coding scheme used to store audio data 
on a disc is continuously variable slope delta 
modulation at 32 kbit/s, which is a comparatively 
simple coding scheme giving good-quality repro¬ 
duction. Dual discs are provided for security and 
designated as main and stand-by. Information is 
written to both discs and played back from the 
main disc; however, if the main disc fails, the 
VSE automatically switches over to the stand-by 
disc for replay; on the first generation VSE1, the 
change-over is manual. 

The VSE2 has a much greater storage space 
than the VSE1: it can hold up to 1000 services, and 
has a maximum of 8000 messages, with up to 23-5 
hours of audio available. The VSE2’s interface to 
the network switches is via standard two-wire 
analogue with DDI signalling. Standard BT in¬ 
coming signalling conditions are used; that is, the 
line potential is sourced by the equipment, and the 
potential is reversed on answer of the call and 
removed during back-busy conditions. 

Messages can be loaded from a collocated 
tape recorder by using special record ports, but 
by using the service definition language, mess¬ 
ages can also be loaded from the normal traffic 
channels. 

Third-Generation VSE 

The VSE3 is a state-of-the-art development 
which has much in common with the VSE2, and 
includes the main functional features of the 
VSE2. The main features of the VSE3 are: 

# the services are defined by using the same 
service definition language as the VSE2, but with 
enhanced capabilities; 


# the ability to fully interconnect in the digital 
domain; 

d better future-proofing capabilities; 

© faster processing; and 

# easier maintenance. 

More channels are available for a given foot¬ 
print: one cabinet holds four VSE3 units and 
serves 120 channels, compared with 60 channels 
with the VSE2 and 30 channels with the VSE1. 

Figure 2 shows a VSE3 cabinet, which stands 
1-8 m high. 

The audio coding scheme used is adaptive dif¬ 
ferential pulse-code modulation at 32 kbit/s, to 
CCITT Recommendation G.721, and offers repro¬ 
duction close to that of the transmission network. 
The storage is 47 hours per 30 channel unit, in 
duplicated disc mode, and the unit is able to handle 
32 000 audio messages and 10 000 services. 

One particular advantage of the VSE3 is its 
ability to provide quality speaker-independent 
voice recognition, for recognising the words 
‘yes’, ‘no’, ‘zero’ and the digits ‘one’ through to 
‘nine’ all as separate words. 


VSE Cluster 

VSE units are each able to handle 30 channels of 
simultaneous and independent traffic, but the 



Figure 2 
VSE3 cabinet 
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• gain access to local statistics; and 
® provide local control of audio file record and 
review. 

Remote connection to the console is also 
possible by using modem access. This has the 
advantage that second-line support can more eas¬ 
ily be given from the central operations unit at 
Oswestry, including the ability to install voice 
services at the RACs remotely. 

Messages may be recorded onto the VSE from 
a collocated source such as a tape recorder by 
using the console to control both the recording 
and the review. 


Service Definition Language 

The fundamental advantage of using the VSE2 
and VSE3 is the ability for BT to develop ser¬ 
vices to MRIS requirements on equipment 
which is basically a proprietary type. The ser¬ 
vice definition language that gives this ability 
is not at too low a level to be time consuming 
and complex to use and not at too high a level 
to be over-restrictive in the functionality pro¬ 
vided. 

In its simplest form, the language is activated 
by an incoming call and consists of a play mess¬ 
age command, which could be followed by a 
jump command to return to the play command 
and repeat the message again. The language 
allows this simple structure to be expanded to 
enable a set number of replays, or play another 
message, or clear the call down and so on. For the 
MRIS services, the resulting programs are con¬ 
siderably more complex than this simple 
example and take account of many added fea¬ 
tures including file management, system admin¬ 
istration and special statistics. 

Examples of the types of commands in the 
service definition language used in the VSE2 and 
VSE3 equipment are: 

• play audio file; 

• record audio file (message) from incoming 
call; 

• detect and recognise dual-tone multi-fre¬ 
quency (DTMF) digits; 

® detect audio activity and spoken words; 

• detect end of audio activity; for example, to 
stop recording an incoming audio file; 

• activate speaker independent recognition; 

Q jump to subroutine or to another service, de¬ 
pending on a detection criterion; and 

• general algorithm control features. 

By using the service definition language it is 
possible to update messages remotely by using a 
dial-up circuit over the public switched telephone 
network (PSTN), controlled by DTMF inband 
signalling. With this method, there is an automat¬ 
ic level control system in the VSE to take account 
of network attenuation and variations in the level 
of the source material and hence to provide a 
reproduced audio level suitable for high-quality 
messages. 
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Figure 3 VSE2 and the VSE3 have the added advantage 

VSE cluster that basic units are able to be interconnected 

by using a local area network and hence form a 
VSE cluster. 

The advantages of clustering are: 

$ audio files are easily transferred between 30 
channel units; 

@ voice applications are easily transferred be¬ 
tween the units in the service definition language 
code; 

® data can be copied between units; and 

• given services may be easily made available 
on greater than 30 channels. 

Figure 3 shows diagrammatically the form of 
a VSE2 or a VSE3 cluster in the RACs. Gener¬ 
ally, four-unit clusters are used, and for added 
security of service provision, given services are 
duplicated on each unit within a VSE pair. 

VSE Console 

A complete cluster of VSE2s or VSE3s is control¬ 
led from a single console, which for security is 
connected separately to each VSE unit, inde¬ 
pendent of the local area network. 

The console allows the MRIS administration to: 

• provide general administration of the VSE; 

• define the voice (application) services by 
using the service definition language; 

• allocate incoming service (DDI) numbers to 
the defined voice services; 

• achieve central activation of the voice ser¬ 
vices; 
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AUXILIARY SWITCH 


Figure 4 
Auxiliary switch 


In providing the MRIS capability at the RACs, 
service provisioning must be flexible so that 
changes, in the traffic generated by the calling 
customers and the changing needs of the service 
provider, can be quickly and efficiently coped 
with. This flexibility point operates as a means of 
directing traffic and selecting channels and ser¬ 
vices, the objective being to make the RAC en¬ 
vironment operate efficiently and to allow the 
operations people to be alerted to changes in 
traffic profiles. This allows a quick response for 
adapting local traffic handling capabilities to the 
changes. 

In simple terms, this requires a switch, but 
this switch needs to be designed for the spe¬ 
cialised MRIS environment for control of voice 
services, by, for example, relieving the relative¬ 
ly expensive VSE from performing pseudo- 
switching tasks. This has resulted in the 
auxiliary switch , which has been developed to 
MRIS specifications. These specifications have 
been produced by the Speech Applications Di¬ 
vision of BT Development and Procurement. 
The equipment, shown in Figure 4, stands ap¬ 
proximately 1-3 m tall and is designed to oper¬ 
ate in a typical operational environment. 

In the RAC environment, the auxiliary switch 
connects to channels from the DSN and forwards 
calls as necessary to the VSEs. The route transla¬ 
tion capability of the auxiliary switch is designed 
to minimise the translating needed in the main 
network and to maximise the traffic on the VSE 
channels. 

Without the auxiliary switch, channels to the 
VSE would be directly related to channels from 
the DSN, and hence, in terms of traffic handling, 
this would lead to a constrained structure and 
inflexibility in responding to real-time traffic 
needs. With the auxiliary switch, the traffic, 
which is offered for voice sendees, can more 
easily be guaranteed to progress to an answered 
state. 

Also, with traffic being channelled via the 
auxiliary switch, statistics for managing the RAC 
environment may be more easily and more use¬ 
fully gathered. The auxiliary switch also gives a 
common access for gathering OPRA statistics. 

In many ways, the development of the auxil¬ 
iary switch has removed the need to develop 
bigger VSE, which otherwise would be essential 
to cater for increased MRIS traffic. Hence, since 
the auxiliary switch provides a flexible front end 
for the incoming traffic, the developments to the 
VSE have been able to concentrate on voice 
features rather than traffic carrying capabilities. 
In the MRIS environment, the auxiliary switch is 
the location where calls are answered, and hence 
call progress tones are inserted at this point. 

Architecture 

An auxiliary switch comprises three switch mo¬ 
dules, each module having 300 channels con¬ 



nected in the form of 10 groups of 30 channels. 
Each group of 30 channels includes an interface 
unit, which determines the signalling system pro¬ 
vided at that periphery of the switch, including 
whether the signalling is incoming or outgoing. 
One aspect of the future-proofing of the switch is 
that the interface units can be replaced by func¬ 
tional units; for example, DTMF digit detectors. 
The switch modules and the interface units, 
shown in Figure 5, together form a complete 
auxiliary switch of 900 channels. Generally, the 
auxiliary switch operates in a totally digital envi¬ 
ronment. All incoming channels and most of the 
outgoing channels connect via 2048 kbit/s 
bearers; hence for connection to VSE with anal¬ 
ogue interfaces, primary-order multiplexers need 
to be used. 

The 2048 kbit/s interface operates on channel- 
associated signalling with a number of signalling 
systems available, although the usual one for the 
MRIS network is the DDI (A 1/B1) system. Com¬ 
mon-channel signalling systems are in develop¬ 
ment for the auxiliary switch. 

Synchronisation 

Two of the 2048 kbit/s bearers from the DSN are 
designated as main and stand-by for synchroni¬ 
sing the auxiliary switch to the network; for syn¬ 
chronisation purposes, automatic switch-over 
occurs should the bearer providing synchronisa¬ 
tion fail. Thus, the auxiliary switch takes syn¬ 
chronisation from the network and forwards that 
synchronisation to the VSE. 
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Figure 5 
Auxiliary switch 
architecture 
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Reliability and Performance 

The auxiliary switch has very high reliability: 
for total failure, the estimated mean-time-be- 
tween-failures is 24 years. This is achieved by 
duplicating common functional areas. For each 
switch module, the central processing unit 
(CPU) provides the main processing and 
switching functions. The CPU is duplicated 
within a module, with each CPU unit holding 
the current database and the real-time call-con¬ 
nection map. Hence if the working CPU fails, 
the duplicated unit can automatically take over 
with the minimum disruption to service. The 
power supply unit for the switch module is also 
duplicated, each with separate power feeds 
from the exchange battery. 

The auxiliary switch can handle 27 000 call 
set ups and 27 000 clear downs every hour. 

Man-Machine Interface 

Control is carried out by the auxiliary switch 
man-machine interface (AS/MMI) software, 
running on a processor external to the auxiliary 
switch, and connected to it via RS232, although 
in later systems a local area network is used. 
The primary function of the AS/MMI is to 
download configuration information and rout¬ 
ing tables to the auxiliary switch. All call-hand¬ 
ling and traffic-handling functions operate 
within the auxiliary switch, and so the AS/MMI 
could be removed and calls could still be 
handled as normal, albeit on the routing infor¬ 
mation loaded before the AS/MMI was 
removed. 


The functions provided by the AS/MMI are at 
two levels: 

# the technician level, and 

# the user level. 

Access to both these levels is separately pass¬ 
word protected. 

Technician Level 

At the technician level, configuration data is pro¬ 
grammed and all channels on the auxiliary switch 
are given logical identities for use at the user 
level. Information so programmed would be ex¬ 
pected to remain stable with only infrequent 
downloading necessary to the auxiliary switch. 
The technician level allows: 

® the switch configuration to be defined; 

© checks to be made on the interface cards in¬ 
stalled in the switch; 

© channels to be grouped and designated incom¬ 
ing or outgoing; and 

€> channel groups to be given logical names for 
reference at the user level. 

User Level 

The user level gives control of the routing tables, 
and hence relates the digits received on groups of 
incoming channels to digits sent out on channels 
selected from groups of outgoing channels. The 
routing tables are expected to be changed fre¬ 
quently, and since it takes a finite time to down¬ 
load routing tables from the AS/MMI, the CPUs 
in the auxiliary switch will hold two routing 
tables, one running and current, and another time 
stamped ready to become current at the defined 
time. In this way, the routing table can be changed 
over smoothly, without loss of calls. After 
change-over, the AS/MMI downloads the next 
routing table to take effect; if only one routing 
table is predefined or if an immediate change of 
routing tables is required, then this can also be 
achieved by the AS/MMI. 

Routing Tables 

An auxiliary switch can accept up to six DDI 
digits from incoming calls, and from these di¬ 
gits call-routing decisions can be made by ref¬ 
erence to the routing table. Up to eight priorities 
of outgoing routes can be specified for each 
incoming digit sequence and the use of wild¬ 
card digits and ELSE conditions can be used to 
make system programming as simple, yet as 
flexible, as possible. Up to 10 outgoing dialled 
digits may be specified for each outgoing route 
and the routing table typically allows up to 1000 
entries. 

The AS/MMI calendar provides 3 months of 
advanced programming for up to 100 different 
routing tables, which are prepared either on the 
AS/MMI or on a remote terminal and transferred 
to the AS/MMI by using a floppy disc. 

As an example, a simplified routing table is 
shown in Figure 6. The incoming group name is 
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shown as ‘CBRAC3’ with a translation given 
against four incoming digits *345, the star indi¬ 
cating that the first digit is a wildcard and in this 
case is not used in the routing decision for the 
outgoing route. The first digit may be used as the 
regional identity for the OPRA statistics. 

The OPRA number given in Figure 6—that is, 
‘ 125’—is the service identity number. For the out¬ 
going route, the table contains the priority number, 
the logical name of the outgoing channel group and 
the digits to be forwarded. In the example, there 
are three options, the first is at priority one which 
connects to channel group ‘ VSE3/A’ and forwards 
digits ‘877’. When all channels in the priority one 
route are busy, then routing would be on priority 
two, and if all these routes are busy, then routing 
on priority seven would be used. There is a hidden 
priority which would give engaged tone if no 
routes are available. 

As well as the priorities that are explicit in the 
routing table, there is also an implied priority for 
internal module routing. This means that at a 
given priority level, the switch always tries to 
route a call out on an outgoing channel that is 
connected to the same switch module as the 
incoming channel. If this is not possible, then 
inter-module routing could be used. In this way, 
it always tries to take advantage of the non-block¬ 
ing characteristic of the switch modules. 

Referring to the routing table in Figure 6, the 
lower portion of the screen is used for editing. 

Switching Functions 

All incoming calls to the auxiliary switch in the 
RACs connect digitally by using A1/B1 channel- 
associated signalling; however the auxiliary 
switch can handle three types of outgoing call: 

% outgoing to DDI connection; 

® outgoing to a broadcast connection; 

# outgoing to a wait-on-start connection. 

DDI Connection 

This is a connection between one incoming chan¬ 
nel and one outgoing channel, with the auxiliary 
switch having the ability to forward up to 10 
digits on the outgoing route. 

Broadcast Connection 

In this case, no DDI digits are forwarded, since a 
continuous audio feed is provided on the out¬ 
going channel. Transmission is provided only in 
the backward direction and many incoming chan¬ 
nels can connect to a single outgoing channel. 
The services thus provided are of the non-start- 
at-the-beginning form, such as for the live com¬ 
mentary of a sporting event. 

The broadcast connection can be provided by 
using a special analogue live-feed interface card. 
This enables an added security of service feature, 
and with this feature the source feed can be 
duplicated to the auxiliary switch and designated 
main feed and stand-by feed. The auxiliary switch 
can operate such that if the main feed goes down 
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for whatever reason, and/or the auxiliary switch 
detects no audio activity on that feed, then the 
switch automatically connects all calls to the 
stand-by feed. 


Figure 6 

Simplified example 
of auxiliary switch 
routing table 


Wait-On-Start Connection 

This connection is analogous to the broadcast 
connection, except that, by controlling the access 
to DDI outgoing routes, start-at-the-beginning 
services can be provided in a broadcast manner. 
With this type of connection, incoming calls are 
queued on the auxiliary switch ring tone for a 
short period, before all calls in the queue are 
connected to a single outgoing DDI service. Be¬ 
cause the queuing period has to be short, for 
example, less than 10 seconds, the connection 
can be used on high-calling-rate services to use¬ 
ful effect. Also in this situation, because a number 
of incoming calling customers are connected to 
a single outgoing route, wait-on-start cannot be 
used for interactive services. 


Call Statistics 

In early installations of the auxiliary switch, 
some compiled statistical information was avail¬ 
able from the AS/MMI, primarily to assist the 
operations personnel in the management of traf¬ 
fic. Later requirements for central service pro¬ 
vider access to call statistics, as part of the OPRA 
work 1 , has instigated the development of a dedi¬ 
cated statistics interface on the auxiliary switch 
to provide raw information over a local area 
network. Because the information is in a raw 
form, it can not only be post-processed for the 
OPRA by using the auxiliary switch call point, 
but also be used to provide the local operations 
personnel with comprehensive information on 
the RAC traffic. 


Raw Information 

The interface, which conveys raw call statistical 
information from the auxiliary switch, contains 
messages of the following form: 


20 


British Telecommunications Engineering , Vol. 11, April 1992 















$ single call data for effective calls, containing 
the OPRA references, hold time, incoming chan¬ 
nel and outgoing channel information; 

• single call data for ineffective calls due to no 
answer, no outgoing routes or switch congestion; 
© accumulated call data for successful calls, 
under circumstances of downtime on the statis¬ 
tics interface; 

• accumulated call data for failed calls; and 

• auxiliary switch database information. 

Auxiliary Switch Call Point 

The auxiliary switch call point performs post¬ 
processing on the raw statistics from up to eight 
auxiliary switches, correlates the information 
against service identity numbers and regional 
identity numbers and forwards the resulting data 
to the central OPRA processor at Oswestry. 

Local Statistics Processor 

The local statistics processor post-processes stat¬ 
istical information for use by the operations per¬ 
sonnel, in order to ensure efficient use of the RAC 
environment. 

VOICE SERVICES 

The equipment and environment so far described 
offer considerable capabilities for providing 
MRIS services. To provide a managed service in 
an environment which is highly flexible, the re¬ 
sultant services must be carefully conceived in 
order to be manageable for the operations person¬ 
nel and comprehensible to the service provider. 
If the service is provided, for example, by allo¬ 
cating areas of audio storage to the service pro¬ 
vider, into which messages can be deposited, then 
the service provider must also be aware of how 
those messages will be accessed and heard by the 
calling customer. 

To achieve this, the MRIS services must be 
generic and the service provider must have pro¬ 
cedures to control the services. 

Generic Services 

The services as perceived by the service provider 
must be generic if they are to be manageable and 
can be described thus: 

• generalised services, suitable for the require¬ 
ments of a number of different service providers, 
yet flexible to fulfil a wide variety of require¬ 
ments; 

6 services initially provided must be easy to 
install by BT, without the need to customise 
application software for every installation; and 

• the interface to the service provider should be 
user friendly. 

Replay-only services are clearly generic. The 
sort of services that would not fall into the generic 
category are highly customised services, such as 
adventure games, which would prove to be a 
significant overhead to support and maintain in a 


managed environment. However, a very wide 
range of services do fall into the generic category. 

Procedures for the Service Provider 

In providing MRIS services, the service provider 
must have procedures to update services and to 
insert information into the services provided to 
the calling customer. 

In the case of the early managed services, 
which were replay only, the only procedure that 
the service provider had to follow was to trans¬ 
port a tape cassette to BT, for manual loading to 
the VSE. This type of procedure, although still 
used, can be restrictive for the service provider in 
terms of the time to update and the need to rely 
on carriers. To give the service provider a more 
controlled option, the remote update (RUD) pro¬ 
cedure was developed. This procedure, which is 
described in more detail later in this article, 
allows the service provider to update his service 
remotely over dial-up PSTN lines by using 
DTMF inband signalling for control. 

Two specialised forms of RUD procedure are 
also used: 

® Remote update/dial-up live feed 
(RUD/DULF) enables the service provider to 
speak direct to the calling customers. This proce¬ 
dure is currently used only on services connected 
via the NAC. 

® Remote update/basic managed interactive 
sendee (RUD/BMIS) gives a nested level of con¬ 
trol for the more complex interactive services 
provided within the BMIS portfolio. 

In the same way that the RUD procedure 
provides the service provider with the ability to 
update services remotely, so the remote down¬ 
load procedure (RDL) allows the service pro¬ 
vider to recover remotely audio information 
captured as a result of calling customers access¬ 
ing services. The type of information captured in 
this way would be, for example, names and ad¬ 
dresses and purchase orders and for this, RDL 
avoids transferring the information to the service 
provider via tape cassettes. 

Services for the Calling Customer 

The services to the calling customer have de¬ 
veloped from the non-start-at-the-beginning 
form, typical with tape recorder technology, to 
the start-at-the-beginning form which became 
possible with the advent of the VSE. Therefore, 
the common form of MRIS services is simply 
message replay. 

More recently, the form of services, as per¬ 
ceived by the calling customer, has been signifi¬ 
cantly enhanced with the development of 
interactive services within the BMIS portfolio. 

Basic Managed Interactive Services 

During 1991, BMIS has been developed to give 
MRIS services the ability to interact with the 
calling customer. In developing BMIS services, 
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two new terms have been used for convenience 
of description: 

© The sendee provider's audio file (SPAF) is a 
message played to the calling customer. The or¬ 
dinary or pre-BMIS services are single SPAT 
services. 

® The caller audio file (CAF) is a message left 
by a calling customer to be conveyed to the 
service provider. 

The BMIS services are based on multi-mess¬ 
age structures in which more than one SPAF can 
be serially provided to the calling customer. The 
service provider can update each SPAF inde¬ 
pendently of other SPAFs by using the RUD 
procedure. SPAFs can be repeated in a single 
service and can be shared between services. Al¬ 
though the multi-message structure is not itself 
truly interactive with the calling customer, it is an 
essential ingredient to achieving the interactive 
service structures. The essential features of 
BMIS services are: 

0 the use of CAFs interleaved with SPAFs; 

O the use of branching structures, based on twin 
branching decisions determined by the calling 
customers responding by saying ‘yes’ or ‘no’; 

© the use of branching within a multi-branch 
structure, with decisions determined by the call¬ 
ing customer responding by saying digits in the 
range ‘1’ through to ‘9’; and 
© a controlled mix of the above features. Control 
is necessary to retain the generic constraint and 
the manageability of the services. 

Therefore BMIS service can be either of a 
non-branching or a branching nature. 



CAF: Caller audio file 
SPAF: Service provider's audio file 


Figure 7 
Typical 

non-branching 
form of BMIS 
service 


service provider’s service, the calling customer 
can be given information on products available 
for purchase and can then have the opportunity 
to leave his/her name and address in one CAF and 
be asked to leave a purchase order effectively in 
a second CAF. 


Non-Branching Form of Service 

Non-branching services are characterised by 
having single entry and single exit points and a 
single fixed path through the service. A typical 
non-branching form of the BMIS service is 
shown in Figure 7, which shows a number of 
SPAFs with three CAFs interleaved. When the 
services are installed, the exact number of SPAFs 
and CAFs are configured according to the service 
provider’s needs, up to a maximum of eight 
SPAFs per service. 

In cases where the CAF storage area is full and 
no more messages from calling customers can be 
stored, calls are automatically connected to the 
default SPAF, which will play a courtesy message 
or promotional message, depending on how the 
service provider has updated that SPAF. If the 
service provider wishes to do a major update to a 
number of SPAFs in his main service, he can 
force all incoming calls to the default SPAF, 
while the update is carried out. This can be done 
by using the enable/disable facility available 
within the RUD/BMIS procedure. 

Non-branching services enable the service 
provider to receive information, such as names 
and addresses, orders for purchasing goods and 
entries to competitions. As an example of the 


Branching Form of Service 

BMIS services also offers the ability to make 
decisions based on voice responses made by the 
calling customer and then to branch within the 
service structure. 

A typical branching form of a BMIS service 
using voice selection, is shown in Figure 8. 
Recognition of the words ‘yes’ or ‘no’ are used 
to gain access to the information. The number 
of branches are set at the time of installation to 
match the service provider’s requirements. If 
the calling customer’s voice cannot be recog¬ 
nised at first, a further two attempts are made, 
after which the default SPAF is played. Other 
branching services can use the recognition of 
spoken digits to choose the branch to be taken 
by the calling customer. CAFs can be inserted 
in the branches. 

As an example of a service provider’s service, 
the calling customer could be asked if he wants 
any information on the best buys in electrical 
goods. If he says ‘yes’, then a message containing 
information on electrical goods is played; if he 
says ‘no’, then other information can be given on 
other questions asked. 

An example of an alternative structure, where 
the calling customer responds with numbers is, 
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SPAF: Service provider’s audio file 


Figure 8 

BMIS service using 
voice selection 


‘if you want information on electrical goods, say 
one; for furniture say two; and so on. 


Remote Update (RUD) Procedure 

The service provider accesses the RUD proce¬ 
dure by dialling a PSTN number to connect, this 
number being different from that dialled by the 
calling customer to access the service. Once the 
procedure has answered, the service provider 
signals by using inband DTMF digits. 
Throughout the procedure, audio guidance mess¬ 
ages are provided to the service provider to help 
achieve the update in a user friendly manner. The 
guidance messages use a consistent voice and 
style to achieve quality procedures. 

Figure 9 shows the RUD procedure in graphical 
form. The service identity code is first signalled, 
followed by a personal identification number 
(PIN). The following options are then available: 

© digit 1 allows the service provider to record a 
message; 


• digit 2 causes the newly recorded message to 
be played back and checked, before it is made 
available to calling customers; 

© digit 4 causes the message currently available 
to the calling customers to be played; 

• digit 3 allows the newly recorded message to 
be made available to the calling customers; 

• digit 6 allows some statistical information to 
be played;and 

• digit # generally halts execution of a previous 
command. 

The RUD procedure as described has been 
available for a number of years and concentrates 
on the update of services containing single 
SPAFs. The procedure has more recently been 
developed to two further procedures; 
RUD/DULF and RUD/BMIS. 

RUD/DULF Procedure 

The RUD/DULF procedure is very similar to 
RUD, but has the added use of the ‘0’ digit to 
enable the service provider to gain real-time 
broadcast access, to the calling customers, from 
within his update procedure. Currently the live- 
feed service, controlled by the RUD/DULF pro¬ 
cedure, is only available over the RIDE 2 
distribution network, where the VSEs are situ¬ 
ated at the NAC. 

The typical use of such a service is for sporting 
events, where the pre-recorded messages provide 
the pre-event and post-event information, but the 
service provider is able to provide live commen¬ 
tary while the event is in progress. 

RUD/BMIS Procedure 

The RUD/BMIS procedure, used for the BMIS 
services, develops the RUD procedure to operate 
at two levels, one level updates the individual 
SPAFs in the service and the second level acts on 
the service as a whole. This enables a complete 
review and provides control of the enable and 
disable facility. 

Remote Down-Load (RDL) Procedure 

The service provider accesses the RDL procedure 
in the same way as for RUD, including the use of 
a service identity and PIN. As with RUD, the 
service provider signals with DTMF and the pro¬ 
cedure provides user-friendly messages for guid¬ 
ance. 

The menu of options is noted below and shown 
graphically in Figure 10. All CAFs received in a 
single call are accessed as a single audio file 
referred to as a caller entry. When the RDL proce¬ 
dure is accessed, statistics on the number of caller 
entries currently held are given verbally to the 
service provider before the menu is entered. The 
commands available in the menu are as follows: 

• digit 2 plays the caller entry, against a current 
entry pointer; 

© digit 1 moves the pointer backwards one caller 
entry and then plays that caller entry; 
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Figure 9 
Remote update 
procedure 


DTMF: Dual-tone multi-frequency PIN: Personal identification number SP: Service provider 



Figure 10 
Remote download 
procedure 


DTMF: Dual-tone multi-frequency SP: Service provider 
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® digit 3 moves the pointer forwards one caller 
entry and then plays that caller entry; 

digit 4 plays caller entries en bloc ; 

# digit 5 controls the deletion of caller entries; 
© digit # generally halts execution of a previous 
command. 


CONCLUSIONS 

MRIS voice services have a solid, well future- 
proofed base of specialised equipment and spe¬ 
cial applications, and the infrastructure is tailored 
to meet the demanding needs of service providers 
wanting the many advantages of managed ser¬ 
vice. The market lead for new MRIS services has 
been strong and continues to be so and this in turn 
has produced a strong influence in the market of 
VSE. 

This article has covered the voice services 
as developed at the end of 1991, but further 
significant features and facilities, not included 
in this article, are under development and are 
expected to become available during future 
years. 
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RIDE: Recorded Information Distribution Equipment 

ERIC ALLARD and TONY WARRENt 


The recorded information distribution equipment (RIDE) system provides a highly-effective means of 
handling traffic to high-calling-rate managed recorded information sendees. This article describes 
the RIDE switch, the RIDE announcement distribution network and the control and management 
aspects of the system. It also details the start-at-the-beginning registration equipment (SABRE) and 
the start-stop generator, which enable RIDE to answer calls with start-at-the-beginning an¬ 
nouncements. 


INTRODUCTION 

Recorded information distribution equipment 
(RIDE) is a system for providing economic mass 
access to recorded announcements and com¬ 
prises a network of specialised fully non-block¬ 
ing digital switches with a centralised 
management system. The system is designed for 
high availability for applications with a high 
customer profile, generating a large number of 
calls. 

RIDE has been developed by the Switched 
Networks Division located at BT Laboratories, 
and was initially used at the London digital junc¬ 
tion switching units to distribute Guideline ser¬ 
vices. The system has been further developed and 
the RIDE switches have now been installed in 
both the derived services network (DSN) and at 
digital main switching unit (DMSU) sites. Within 
the DSN, the RIDEs are located at recorded 
announcement centres (RACs) at the eight DSN 
nodes. 

The use of the RIDE in the DSN enables 
recorded information service announcements to 
be distributed from a central location, the na¬ 
tional announcement centre (NAC), to all the 
RIDE switches. Calls to the announcements are 
then delivered from the DSN to the local RIDE 
switches. This arrangement reduces the demand 
on the DSN’s transmission and switching capac¬ 
ity by only switching calls through one DSN 
node to the RIDE switch. It also provides for a 
large number of answering points for the 
announcements. Without the RIDE, calls to popular 
announcements would be switched via DSN inter- 
nodal routes to the DSN node providing the an¬ 
nouncement. This would result in many of the 
circuits on the inter-nodal routes carrying the same 
information, with the number of simultaneous 
calls to an announcement restricted to the number 
of access channels available on the recorded an¬ 
nouncement machine at the particular DSN node. 

The RIDE distribution network carries infor¬ 
mation in one circuit to all of the DSN exchanges, 
thus reducing the demand on transmission and 
switching capacity. Coupled with the greatly in¬ 
creased number of access channels provided by the 
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RIDE switching nodes, this network significantly 
reduces congestion at periods of peak demand. 

The RIDEs at the DMSU sites have been used 
to answer misdialled calls for the London code 
change, providing courtesy announcements to 
the callers. In the future, the DMSU RIDEs will 
be interconnected by ring distribution networks 
to allow the system to be used for distributing 
Timeline services, announcements for the forth¬ 
coming national code change and to support 
high-volume televoting services. 

This article describes the basic RIDE switch and 
its distribution network. It also describes the start- 
at-the-beginning registration equipment (SABRE) 
enhancement to enable the RIDE to answer calls to 
the recorded information services with start-at- 
the-beginning (SAB) announcements, and the 
system management function required to control 
and manage the network of RIDE switches. 

Announcement Distribution 

The recorded information announcements fed to 
the RIDEs are carried in 64 kbit/s channels of 
2 Mbit/s pulse-code modulation (PCM) systems. 
These are connected to form a distribution ring 
which links all of the RIDE switching nodes. In 
practice, these systems are duplicated and use 
diverse routing over higher-order systems to 
maintain the distribution under fault conditions. 
Figure 1 shows this network. 

Recorded announcements, by their nature, re¬ 
quire only distribution, which would leave the 
return direction of transmission of the PCM sys¬ 
tems unused. By using a ring network, both trans¬ 
mit and receive directions are available to 
distribute announcements, doubling the capacity 
of the network. The use of a ring also allows the 
returning announcement to be monitored to 
check the integrity of the distribution network. 

Each RIDE switch obtains access to the ring 
network via 2 Mbit/s splitter equipment which 
provides ‘tapped’ 2 Mbit/s feeds to the RIDE 
switches, while maintaining the integrity of the 
ring network. 

The recorded information services are fed 
from the NAC, at Oswestry, on four 2 Mbit/s 
rings connecting all eight RACs. A maximum of 
120 messages can be distributed from the NAC 
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OPRA: Opinion poll registration application 
RIDE: Recorded information distribution equipment 
SABRE: Start-at-the-beginning registration equipment 


Figure 1 to the eight RACs, where the RIDE switches 

RIDE network incoming calls to the messages. 

Switching 

The services provided by the RIDE switches are 
non-start-at-the-beginning (non-SAB), which 
means that many calls can connect to the same 
announcement, but each new caller will probably 
start to listen to a partially completed message. 

The RIDE network has been enhanced to pro¬ 
vide it with an SAB capability. The enhancement 


Figure 2 
RIDE switch 



RIS: Recorded information sendee 
SABRE: Start-at-the-beginning registration equipment 


consists of a modification to the software running 
on the RIDE network and additional equipment, 
called start-at-the-beginning registration equip¬ 
ment (SABRE), installed in each RIDE switch. 

The SABRE system stores a copy of the non- 
SAB announcements in random-access memory 
(RAM). When an announcement is replayed to a 
customer, the SABRE retrieves the samples se¬ 
quentially from the beginning. With this en¬ 
hancement, the RIDE is thus able to answer calls 
with an SAB version of the distributed an¬ 
nouncements. 

Data on the calls to the various recorded ser¬ 
vices provided by the RIDE is collected and 
passed to the opinion poll registration application 
(OPRA) system 1 . This system allows the data 
collected to be accessed by the service providers. 

THE RIDE SWITCH 

Overview 

The RIDE switch uses digital switching based on 
a central broadcast bus. This arrangement allows 
announcements from the recorded information 
services feeds to be presented on the bus, and be 
accessed by a large number of calling channels. 
The system enables any number of calling chan¬ 
nels to be connected to any announcement ser¬ 
vice, or all of the calling channels to any one 
announcement service. 

The primary function of the RIDE switch is to 
connect calls from an associated exchange to the 
requested recorded information service. The re¬ 
corded information services and the calls from 
the exchange are presented to the RIDE as digital 
64 kbit/s channels within a 2 Mbit/s PCM sys¬ 
tem. The switching function is used to connect 
the calling customer's channel to the channel 
carrying the required announcement. The appro¬ 
priate recorded information service is selected by 
interrogation of the dialled digits received in the 
channel-associated signalling carried by the 
2 Mbit/s streams from the exchange. Figure 2 
shows a basic block diagram of the RIDE switch. 

The channels carrying the recorded informa¬ 
tion services are terminated on input cards, with 
one input card terminating a single 2 Mbit/s 
system. The maximum configuration of the 
RIDE will handle up to 120 duplicated services 
with eight input cards installed. Each input card 
converts the received signals to transistor-tran¬ 
sistor logic levels and switches them on to the 
serial bus within the system. The first three input 
cards also provide the RIDE internal synchroni¬ 
sation and the synchronisation to its external 
2 Mbit/s interfaces. An input processor is pro¬ 
vided on each input card to provide control and 
monitoring of the 2 Mbit/s interface and other 
functions. 

As an alternative to providing announcements 
from the ring via the input cards, the RIDE may 
also be equipped with announcement cards 
which provide the announcement source. Each 
announcement card provides five 65 s 
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announcements onto the serial bus in the same 
way as an input card. These cards replace input 
cards 5 to 8 and therefore reduce the an¬ 
nouncement channel capacity of the RIDE if they 
are fitted. To provide duplication of an¬ 
nouncement sources, announcement cards are 
installed in pairs, with identical announcements 
recorded on each of the pair of cards. 

The channels carrying the customers’ calls 
from the exchange are terminated on output 
cards, each handling two 2 Mbit/s systems. Up to 
12 output cards can be provided to give the RIDE 
a total call handling capability of 720 channels 
on 24 x 2 Mbit/s systems. Each output card has 
two digital time/space crosspoint switches, one 
dedicated to each terminated 2 Mbit/s stream. 
The crosspoint switches provide the switching 
function, connecting channels in the 2 Mbit/s 
streams to the recorded information service chan¬ 
nels on the system’s serial bus. The call-control 
function is provided by two output selection pro¬ 
cessors; an output selection processor is associ¬ 
ated with a time/space crosspoint switch. 

A request for a particular service is carried by 
dialled-digit information in the incoming signall¬ 
ing received by the RIDE, which connects the 
call to the appropriate service. Any service may 
optionally be prefaced by ring tone, a pre-an¬ 
nouncement or both. The pre-announcement may 
be provided as SAB or non-SAB. This control 
data is held in a parameter table which is accessed 
by the output selection processor in setting up the 
call. 

An important function of the RIDE is to pro¬ 
vide management information for statistics, 
maintenance and diagnostics purposes. (The stat¬ 
istical information is also passed to the OPRA 
system.) This function is provided by a supervi¬ 
sory processor which has communication paths 
with all output selection processors, input pro¬ 
cessors and the SABRE control processor. The 
supervisory processor, in turn, is controlled from 
a management system that also allows operator 
control of the system. Figure 3 shows the connec¬ 
tion of the processors. 

The management system routinely requests 
system management information, including 
alarms and call statistics, from the RIDE and 
also sends control information to the RIDE to 
invoke further action. In response to these com¬ 
munications from the management system, the 
RIDE replies with the required information or 
with an appropriate response. A message proto¬ 
col is used on the link between the management 
system and the RIDE to give an acceptable data 
transmission performance. Should the com¬ 
munication link or the management system fail, 
the RIDE is able to perform all telephonic func¬ 
tions in isolation. 

Switching Function 

The switching function is the primary function of 
the RIDE. It is provided by the input and output 
cards connected by the passive serial synchron- 



Figure 3 
Connection of 
RIDE processors 


ous bus system. Figure 4 shows a block diagram 
of the RIDE switching function. 

Each input card terminates a 30-channel non- 
SAB recorded information service stream, aligns 
the data, and transmits it onto two serial synchron¬ 
ous bus lines. One bus line is connected to all of 
the output cards, the other direct to the SABRE. 

Separate bus lines are supplied for each input card. 

Two more bus lines from each input card, one 
connected to all the output cards, the other directly 
to the SABRE, carry a signal that indicates the 
‘health’ of the recorded information service 
stream. 

The arrangement allows the RIDE to handle 
up to 120 non-SAB services. The SABRE pro- Figure 4 

vides conversion of any 60 out of the 120 non- RIDE switch 

SAB services to SAB format. functional blocks 



RIS: Recorded information service 
RIDE: Recorded information distribution equipment 
SABRE: Start-at-the-beginning registration equipment 
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The use of a synchronous bus system re¬ 
quires that clock signals are distributed with the 
data. The RIDE uses a triplicated clock scheme, 
with the clock generation on three input cards 
(cards 1 to 3) which are interconnected to en¬ 
sure synchronisation of the distributed wave¬ 
forms. 

This arrangement of input cards ensures that 
failure of any one card does not affect the oper¬ 
ation of the RIDE switch. 

Each output card terminates two 30-channel 
PCM systems from the exchange, and has an 
output selection processor dedicated to each 
PCM system. The output selection processor in¬ 
spects the signalling information from the ex¬ 
change for the 30 speech channels and instructs 
its associated crosspoint switch to set up the 
appropriate connection. The crosspoint switch 
can connect any channel on the PCM system to 
any channel on any of the non-SAB serial bus 
lines, or to any channel in the SAB serial line 
from the SABRE. Amaximum of 12 output cards 
can be plugged in to a RIDE. 

Each output selection processor uses a separ¬ 
ate serial line to instruct the SABRE to replay 
services in SAB format. 

Failure or removal of any one output card does 
not affect the service on any other output card. 

Failure of the SABRE prevents the RIDE 
switch from providing SAB announcements. 
However, the switch is still able to answer calls 
with non-SAB versions of the services affected. 

Input Card 

The input card terminates a 2 Mbit/s tap from the 
recorded information service ring, and the 30 
speech channels are connected through a 
time/space crosspoint switch and then buffered 
onto a serial backplane bus to output cards and a 
serial line to the SABRE. The switch device is 
not used to perform a switching function, but is 
used to allow the input processor to access the 
alarm and signalling conditions generated by the 
PCM interface. If the alarm conditions indicate a 
particular stream is faulty, the input processor 
signals this to the output cards and to the SABRE. 

The PCM signalling is monitored to detect 
START and STOP of service replays, and an indi¬ 
cation of the replay status is passed to the SABRE 
over the serial line. 

Each input card has the ability to synchronise 
a local oscillator to the recorded information 
service stream, but this facility is only used on 
the first two input cards. The first three input 
cards combine to form a triplicated clock and 
waveform generator to supply the rest of the 
RIDE switch. Two waveforms are distributed, a 
4 096 MHz clock and a frame vector. 

The distributed clock and frame vector are 
used by various devices on the input and output 
cards and the SABRE cards. Each card uses 
majority decision logic to obtain a single clock 
and frame vector from the triplicated distribu¬ 
tion. 


Announcement Card 

An announcement card provides five fixed an¬ 
nouncements that are buffered onto a serial back¬ 
plane bus. Each of the announcements is stored 
as 8-bit PCM samples in eight EPROMs. A 
counter is used to read out each of the locations 
of the EPROMs in turn. Data is simultaneously 
read from five EPROMs, one for each an¬ 
nouncement, and fed to five parallel-to-serial 
convertors. The outputs from the five convertors 
are then multiplexed to give one serial output 
stream. 

Output Card 

An output card can connect a recorded informa¬ 
tion service, carried in any channel on any of the 
eight serial bus lines, or one of the two serial lines 
from the SABRE, to any channel in either of two 
30-channel PCM connections to the exchange. 

An output selection processor accesses the 
crosspoint switch over the processor address and 
data bus. Registers within the device allow the 
output selection processor to read and write sig¬ 
nalling information for the PCM interface and the 
SABRE; read the alarm status of the PCM inter¬ 
face; and set up connections across the switch 
according to dialled digit information from the 
PCM signalling stream. The output selection pro¬ 
cessor determines the status of a particular non- 
SAB announcement feed by inspecting the 
‘stream health’ status line associated with it. 

If connection to a requested service is not 
possible, connection is made to number unob¬ 
tainable (NU) tone. The NU tone is generated on 
the card and connected to one of the crosspoint 
switch inputs. A ‘silence’ tone (that is, the idle 
pattern) is also generated within the switch de¬ 
vice and is connected to idle channels. 

One input to and one output from the 
time/space crosspoint switch are used for switch¬ 
ing calls from the exchange to a SAB an¬ 
nouncement feed from the SABRE. Signalling 
information requesting the SABRE to play a 
particular message in a particular channel is sent 
to the SABRE, and an indication of the success 
or failure of the request is returned by the 
SABRE, which then starts the service playing, if 
available. 

Supervisory Processor 

The supervisory processor is a proprietary rack 
system based upon the STE bus. The bus master 
processing element is a single CPU card with 
on-board RAM, EPROM, serial I/O, and counter 
timers. There is also a system controller card to 
oversee the functions of the bus system. Addi¬ 
tional memory is provided by a non-volatile 
memory board which also has a real-time clock 
capability. Nine 4-port intelligent serial I/O cards 
provide the interface to the input cards, output 
cards, SABRE and the management system link. 
Each intelligent serial I/O card includes a single 
CPU with on-board RAM and EPROM. A non- 
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intelligent 4-port serial I/O card provides an in¬ 
terface to an optional printer. All communication 
links are serial asynchronous bidirectional 
RS232 connections. 

RIDE Cabinet 

Physically the RIDE switch is provided in a 
19 inch free-standing cabinet. Input cards and 
output cards are provided in two shelves in the 
cabinet, interconnected by backplanes, one in 
each shelf, which in turn are interconnected by 
dedicated cables. 2 Mbit/s connectors are by 
75 Q. cables that terminate directly on the back¬ 
planes. 

Mounted above the shelves for the input cards 
and output cards is the supervisory processor. 

The SABRE unit is provided in a shelf 
mounted at the bottom of the cabinet below the 
input cards and output cards. 

Power for the input cards, output cards and the 
SABRE is provided from the 50 V DC exchange 
supply; power for the supervisory processor is 
240 V AC mains. 

Figure 5 illustrates the RIDE cabinet. 

SABRE 

Overview 

To enable the basic non-SAB RIDE to provide 
SAB announcements, it is equipped with a 
SABRE attachment. This stores a copy of the PCM 
samples of the non-SAB services in RAM. When 
an announcement is connected to a calling cus¬ 
tomer, the SABRE retrieves the samples from 
memory to replay the announcement as an SAB 
announcement. Figure 6 shows a block diagram of 
the SABRE. 

A fully-equipped RIDE is provided with 120 
duplicated announcements on eight 2 Mbit/s in¬ 
puts. The SABRE can be configured to record up 
to 60 of these announcements. In the event of one 
of the duplicated inputs failing, or failure of the 
RIDE input card, the SABRE automatically rec¬ 
ords from the alternative input. 

The selection of which 60 of the 120 services 
SABRE records is dependent on data held in an 
EPROM located on one of the SABRE cards. To 
change the selection, the EPROM device is re¬ 
placed with a device containing the new selection 
data. 

The maximum length of the messages that can 
be stored by the SABRE is fixed; 48 of the 
recorded services have a maximum length of 
approximately 4*3 minutes, the remaining 12 
have a maximum length of approximately 8-6 
minutes. The SABRE raises alarms if an attempt 
is made to record an announcement that is too 
long. 

The SABRE enhancement enables the RIDE 
to connect all of the 720 possible simultaneous 
calls to SAB announcements. There is no limita¬ 
tion as to how many calls may be connected to 
any of the announcements, so if required, all calls 


Figure 5 
RIDE cabinet 
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could be connected to a single announcement, or 
distributed across 60 different announcements. 

When the SABRE has replayed the complete 
announcement to the caller, it repeats it again 
from the beginning. This will continue until the 
caller clears down, or the RIDE output card force 
releases the connection to the caller. 

The SABRE control is integrated into the 
RIDE control system. Alarms raised by the 
SABRE unit are passed to the management sys¬ 
tem, and commands to control the SABRE are 
available on the management system. Figure 6 

The SABRE has circuitry to check the inte- SABRE functional 
grity of the announcement storage memory, blocks 


COMBINED SIGNALLING AND 
SPEECH DATA FROM 
RIDE INPUT CARDS 
(MAXIMUM 8) 


SIGNALLING BETWEEN RIDE 
OUTPUT CARDS AND SABRE. 
REPLAYING ANNOUNCEMENT 
DATA FROM SABRE TO RIDE 
OUTPUT CARDS 
(MAXIMUM 24) 
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Figure 7 
Connection of 
RIDE input and 
RIDE output 
cards to SABRE 


Memory failures are reported to the management 
system. Under exceptional circumstance, calls 
which are destined for an SAB announcement 
that is unavailable because of a fault condition 
are connected by the RIDE output card to the 
non-SAB version of the announcement. 

Recording Announcements 

The voice service equipment (VSE) 2 at the NAC 
providing the recorded announcements continu¬ 
ously relays the repeating announcements in all 
channels of the 2 Mbit/s inputs to the RIDE input 
cards. 

For each of the 60 channels selected for SAB 
conversion, services are supplied via the start- 
stop generator equipment, also located at the 
NAC. The start-stop generator indicates that an 
announcement is playing by setting a code in the 
signalling field of the 2 Mbit/s PCM multiframe 
for the channel carrying the announcement. For 
channels that have not been selected for SAB 
conversion, no signalling is required from the 
equipment, but if signalling does appeal* for these 
channels it is ignored. 

Hardware on the RIDE input cards extracts 
the signalling from the multiframe and performs 
a persistence check. Software then compresses 
the signalling data which is to be sent to the 
SABRE. The channels containing the received 
announcements are transparently switched 
through the input card, combined with the sig¬ 
nalling data and sent to the SABRE in serial data 
streams. 

The signalling data from the RIDE input cards 
is extracted by the SABRE control processor to 
determine when a non-SAB announcement is 
about to repeat. The serial announcement data is 
converted to parallel format and held in a tem¬ 


RIDE 



porary store until it can be transferred to the 
announcement memory. 

The Announcement Memory 

For each of the 60 announcements that the 
SABRE can record, a dedicated block of RAM is 
reserved within the announcement memory ad¬ 
dress range. When the SABRE control processor 
detects that a particular announcement is about 
to start, it instructs the SABRE hardware to rec¬ 
ord the PCM samples of the announcement se¬ 
quentially in the RAM reserved for that 
announcement. However, access to the an¬ 
nouncement memory is time shared between the 
60 updating channels and the replaying channels, 
hence the need for temporary storage of the an¬ 
nouncement data for each channel until it can be 
put in the announcement memory. 

Replaying 

An incoming call is handled by an output selec¬ 
tion processor on a RIDE output card. The 
dialled-digits information allows the output se¬ 
lection processor software to determine if an 
SAB service is required. The output selection 
processor requests a particular announcement 
from the SABRE by sending a message to the 
SABRE control processor. The request is ac¬ 
knowledged by the SABRE control processor by 
a return message. 

The RIDE is able to serve up to 720 simulta¬ 
neous incoming calls, all of which may request 
an SAB service. For each replaying channel, the 
SABRE control processor instructs the SABRE 
hardwaie to retrieve samples from the memory 
allocated to the requested announcement, when 
it is the turn of that particular replaying channel 
to access the announcement memory. 

The retrieved samples are temporarily stored 
until they can be converted to a serial stream and 
sent to the output card that requested them. 

Interfaces 

The SABRE is connected to the RIDE input and 
output cards by 2 Mbit/s serial streams. The bit 
stream is divided into a 32 time-slot format. The 
RIDE input cards also provide the SABRE with 
triplicated system clocks for the timing of these 
streams. Figure 7 shows the connection of the 
RIDE input and the RIDE output cards to the 
SABRE. 

The eight connections to the RIDE input cards 
are unidirectional from the RIDE input cards to 
the SABRE. The 30 time-slots on each stream are 
used to transmit the non-SAB services to the 
SABRE, from which it records the PCM samples 
of the services. The remaining two are used to 
signal to the SABRE whether or not an an¬ 
nouncement is playing in each of the 30 an¬ 
nouncement channels. 

The connections to each of the RIDE output 
cards are bidirectional. The 30 time-slots in each 
stream from the SABRE to the RIDE output 


British Telecommunications Engineering , Vol. 11, April 1992 


31 
































cards are used to replay the requested SAB an¬ 
nouncement; two time-slots are available in each 
direction for a message-based signalling system 
to set up the call. 

The SABRE communicates with the RIDE 
supervisory processor over the bidirectional 
RS232 link. This is used to receive command 
instructions from the management system and to 
report alarm conditions. 

Outline of SABRE Hardware 

The SABRE consists of fifteen cards intercon¬ 
nected by a backplane, and a DC-DC converter 
to supply the cards with the required voltages 
from the exchange -50 V supply. There are five 
different types of card: 

• signalling card, 

# controller card, 

® memory card, 

• update card, and 

# access card. 

The cards are described below. 

Signalling Card 

The SABRE has a single signalling card that 
provides the interface to the signalling from the 
RIDE input cards, indicating that a non-SAB 
announcement has started to repeat, and signall¬ 
ing from the RIDE output cards to set up a call to 
a particular SAB announcement. The SABRE 
control processor, with its program memory, is 
physically located on this card, but can control 
peripheral devices that are located on other 
SABRE cards over the backplane. 

Controller Card 

The SABRE has a single controller card. Access 
to the announcement memory, where the an¬ 
nouncements are stored, is shared between the 60 
channels that need to write in new messages and 
the 720 channels that want to retrieve the stored 
sample. It is the controller card, under instruction 
from the SABRE control processor, that sets up 
the address and control lines for the memory 
cards for each channel in turn. 

Memory Card 

The SABRE has nine memory cards, each hold¬ 
ing eight 4-3 minute announcement units, giving 
a total of 5* 16 hours of announcement storage. 
The announcement memory is constructed from 
dynamic RAM devices. 

Update Card 

A single update card provides the SABRE with 
an interface to the eight streams of announcement 
messages from the RIDE input cards. It is on this 
card that the selection is made as to which one of 
the duplicated streams will be used to make the 
recording, and which 60 of the possible 120 
different announcements will be recorded. 


This card also temporarily stores the PCM 
samples until they can be written into the an¬ 
nouncement memory. 

Access Card 

There are three access cards in the SABRE sys¬ 
tem. Each card provides the interface to four 
RIDE output cards over the replay data streams. 
The access card provides a temporary store for 
the announcement data retrieved from the an¬ 
nouncement memory until it can be sent to the 
RIDE output cards. 

START-STOP GENERATOR 

In order to provide the SABRE with signalling to 
indicate the start and stop of an announcement, 
an additional piece of equipment, known as a 
start-stop generator , is used to provide this sig¬ 
nalling, in conjunction with the VSE servicing 
the announcement. The start-stop generator com¬ 
municates with the VSE to detect the start of the 
announcement, and then sets a code in the sig¬ 
nalling field of the 2 Mbit/s PCM multiframe for 
the channel over which the announcement is 
distributed. This code is detected by the SABRE, 
as described earlier. 

The start-stop generator itself is provided as a 
shelf of equipment provided at the head of the 
RIDE rings at the NAC. The start-stop generator 
is able to signal over 60 duplicated channels of 
the 120 duplicated channels distributed to the 
RIDEs. 

SOFTWARE FUNCTIONAL 
DESCRIPTION 

The software of the RIDE and the SABRE has its 
functionality divided into a number of functions 
spread across the hierarchy of processors. These 
functions are: 

% call handling which covers all telephonic 
aspects and, in particular, monitors the time-slot 
16 signalling from the exchange interface and 
connects calls accordingly. It runs only on the 
output selection processor and the SABRE con¬ 
trol processor. 

© system management which includes all non- 
telephonic aspects. This can be split into three 
main areas: alarms, call statistics and commands. 
® inter-processor communications which is 
responsible for carrying all communication be¬ 
tween processing sites. It uses special protocols 
between all communicating processors to ensure 
the reliable transmission of data. 

SYSTEM MANAGEMENT 

A hierarchy of processors is used to monitor and 
control the RIDE network. This allows the cen¬ 
tralised collection of call statistics, centralised 
alarm monitoring and issuing of commands. Four 
of the processors in the hierarchy are within each 
REDE switch: 
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• supervisory processor, 

• input processor, 

• output selection processor, and 
® SABRE control processor. 

Communication between the supervisory pro¬ 
cessor and the other processors is by means of 
serial RS232 links. 

Overall system management of each RIDE 
switch is performed by a recorded information 
services control processor (RISCP), and the three 
system management functional areas—alarms, 
commands and call statistics—are described 
below. 

Alarms 

Each of the processors within the RIDE monitor 
their associated hardware areas and interfaces, 
and generate alarms if faults or exception condi¬ 
tions are detected. 

The output selection processor generates 
alarms for the following: 

• faults detected on the 2 Mbit/s PCM interface 
to the exchange, and 

• faults detected on the interface with the 
SABRE. 

The input processor generates alarms for the 
following: 

• faults detected on the 2 Mbit/s PCM interface 
to the recorded information service ring, and 

• faults detected in the synchronisation system. 

The SABRE control processor generates 
alarms for faults detected within the SABRE 
hardware. 

The supervisory processor generates alarms 
for loss of communications with other processors 
(output selection processor, input processor, or 
SABRE control processor). 

In addition, each processor monitors itself for 
internal processor faults, and its associated hard¬ 
ware, and generates alarms if faults are found. 

All alarm conditions are collected regularly 
by the supervisory processor, which builds a fault 
record for the RIDE. When requested, the fault 
record is passed to the RISCP by the supervisory 
processor. 

Commands 

The commands function allows an operator at the 
RISCP to interrogate and control a particular 
RIDE or a number of RIDEs. 

The following types of operation are avail¬ 
able: 

• further interrogation of alarms information 
received to identify fully a fault within the RIDE, 

• control of the RIDE call-handling function by 
which the operator is able to clear calls in pro¬ 
gress, or prevent new calls from being handled, 
and 

• requests for statistics information (configura¬ 
tion information, number of calls in progress etc). 


Any commands request from the RISCP is 
received as an inter-processor message by the 
supervisory processor. The supervisory proces¬ 
sor either acts on the request itself, or forwards 
the message to other processors for action. Once 
the required action has been performed, a re¬ 
sponse message is sent to the RISCP. If the re¬ 
quired action cannot be carried out, an error 
message is sent to the RISCP. 

Call Statistics 

For every call that is completed on the RIDE, the 
output selection processor generates a statistics 
record. All output selection processors’ statistics 
records are then, in turn, regularly collected by 
the supervisory processor for further processing. 
The statistics information is then made available 
in two ways: 

# on a per-call basis output to an external printer 
connected to the supervisory processor, or 

# as total calls and call duration to a particular 
recorded information service and fed into a stat¬ 
istics record. This record is passed to the RISCP, 
on demand, and is subsequently passed to the 
OPRA 1 system. 

Recorded Information Services Control 
Processor (RISCP) 

The RISCP provides centralised management 
of the RIDE, and can control up to 10 RIDE 
switches. It is based on a BT personal computer, 
equipped with additional cards to provide the 
serial ports for communication to the RIDEs. It 
also provides a serial connection to the OPRA 
system for the transfer of call-statistics infor¬ 
mation. Figure 8 shows the configuration of the 
RISCP. 

The RISCP performs the following functions: 

# it sends poll messages to its RIDEs every 30 s 
to collect alarm information, 

® it sends poll messages to its RIDEs every 
minute to collect call statistics information which 
is then forwarded, on demand, to the OPRA, and 

# it sends control information to one or all of 
its RIDEs in response to requests from the oper¬ 
ator. 



Figure 8—RISCP configuration 
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Man-Machine Interface 
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The RISCP also provides a man-machine inter¬ 
face (MMI) to allow an operator to interact with 
the RIDE system. A typical screen display pro¬ 
vided as part of the MMI is shown in Figure 9. A 
banner is displayed at the top of the screen, and 
this shows the current status of all the RIDEs 
connected to the RISCP. The status shows if 
prompt or deferred alarms exist, and shows any 
alarms that have been marked receiving atten- 
TlON.The remainder of the screen provides a 
dialogue area for display of commands entered 
into the system and responses received. 

Control of the system is by keyboard entry and 
certain commands are password protected. 
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RIDE System Management Unit 

In order to control the DSN and DMSU RIDEs 
from the NAC a total of eight RISCPs are re¬ 
quired. The RIDE system management unit pro¬ 
vides a rationalised approach, reusing the 
RISCPs to provide a system where all the RIDEs 
can be managed from a pair of workstations. The 
RIDE system management unit is described fur¬ 
ther in a separate article in this issue of the 
Journal 3 . 
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Opinion PolD Registration Application 

MICHAEL BOOMERt 


The opinion poll registration application (OPRA) system collects call statistics data from recorded 
information distribution equipment (RIDE) and the auxiliary switch within the managed recorded 
information setyices (MRIS) platform. Sendee providers are then able to access OPRA to obtain 
statistics for their setyices. This article describes the sendees offered by OPRA and provides a history 
ofOPRA’s development and an architectural description of the present system. 


INTRODUCTION 


Detailed Statistics 


The opinion poll registration application 
(OPRA) system is a means of providing service 
providers with on-line access to call statistics for 
services delivered on the managed recorded in¬ 
formation services (MRIS) platform. 

Two OPRA systems are provided at the na¬ 
tional announcement centre (NAC). One system 
collects call statistics data from the recorded 
information distribution equipment (RIDE) sys¬ 
tems 1 , in the derived services network (DSN), 
and provides service providers with on-line ac¬ 
cess to the data for calls to the particular service 
provider’s announcements answered by RIDE. 
The second system collects call statistics data 
from the auxiliary switches 2 , and provides ser¬ 
vice providers with data on calls answered by the 
auxiliary switches. 

This article describes the on-line statistics ser¬ 
vices offered by OPRA, and then provides an 
overview of the architecture of the OPRA sys¬ 
tems. A history of the development of OPRA is 
then given, followed by a more detailed descrip¬ 
tion of the present systems. Finally, future devel¬ 
opments of OPRA are considered. 

ON-LINE STATISTICS 

Service providers can access the on-line statistics 
services in two ways: 

• by using a personal computer (PC) connected 
to a public switched telephone network (PSTN) 
line, terminated by a BT NS2232B modem con¬ 
nected to OPRA, to collect data that can be 
displayed on, or further processed by, the PC; or 

• by using a TouchTone™ telephone connected 
to a PSTN line to receive data as spoken mess¬ 
ages automatically generated by the OPRA sys¬ 
tem. 

Three basic types of call statistics data are 
available on-line to the service providers: 


The detailed statistics services provide detailed 
information on single numbers (an¬ 
nouncements), with statistics updated every 15 
minutes. The reports generated contain statistics 
giving both call counts and accumulated call 
holding times (in seconds) for each 15-minute 
period. Where a service provider’s an¬ 
nouncement is provided nationally (for example, 
on REDE), the reports also provide a breakdown 
of statistics, split over eight geographical re¬ 
gions. Access to the detailed statistics services is 
by using a PC connected to OPRA via a modem 
connection over the PSTN. Using a dial-up/dial- 
back protocol for security of access, service pro¬ 
viders are able to access the statistics and display 
them, or process them further, by using the PC. 
The detailed statistics services are not available 
by using the TouchTone telephone method of 
access. The services are available however from 
both OPRA systems—the DSN RIDE OPRA, 
and the auxiliary switch OPRA. 

Summary Statistics 

The summary statistics services provide informa¬ 
tion on a group of numbers (announcements), 
with statistics updated every 15 minutes. The 
reports generated contain data on up to 16 num¬ 
bers, and consist of counts of the total calls to 
each of the numbers since the service was started 
or last reset. The reports also provide a break¬ 
down of the data, split over eight geographical 
regions. Access to the summary statistics ser¬ 
vices is via a PC (as for the detailed statistics 
services), or by using a TouchTone telephone to 
obtain automatically-generated spoken reports. 
With both types of access, the service provider is 
able to reset the counts for his/her an¬ 
nouncements. The services are available from 
both OPRA systems—the DSN RIDE OPRA and 
the auxiliary switch OPRA. 


• detailed statistics, 

• summary statistics, and 

• one-minute statistics. 


t BT Development and Procurement 


One-Minute Statistics 

The one-minute statistics services are similar to 
the summary statistics services, but the call data 
is accumulated every minute. Access is via a PC 
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or a TouchTone telephone. The services are only 
available from the DSN RIDE OPRA system. 

A service provider may have several recorded 
information services active at any one time. Each 
recorded information service supports an an¬ 
nouncement for a detailed, summary or one- 
minute service. 

Each OPRA system accommodates a maxi¬ 
mum of 2000 service provider customers, 2000 
services and 2000 announcements. The collected 
data is held for up to seven days, and a separate 
file is created for each service and each day’s 
collected data. At the NAC, the operator admin¬ 
istration functions on OPRA provide facilities for 
defining customers, services and associated re¬ 
corded announcement channels on the RIDEs, or 
announcements on the auxiliary switches. 

A description of the operations performed by 
NAC personnel in using the OPRA to provide 
services is more fully described in another article 
in this Journal 3 . 

OVERVIEW OF THE ARCHITECTURE 
OF OPRA 

OPRA is a real-time computer system, based on 
a central OPRA processor, that can collect data 
on calls answered by the MRIS platform and 
deliver the data to service providers via connec¬ 
tions over the PSTN. The system also provides 


administration access for operators at the NAC. 
The two OPRA systems provided at the NAC 
collect data from the DSN RIDE system and the 
auxiliary switches. Schematics of the two sys¬ 
tems are shown in Figures 1 and 2, respectively. 

OPRA communication between the RIDEs is 
via asynchronous serial data links (see Figure 1), 
and between the auxiliary switches is via Ether¬ 
net connections over the NAC-RAC communi¬ 
cations network (see Figure 2). Both systems 
provide service provider on-line access by using 
PCs via PSTN lines terminated by modems. Ten 
lines are provided per OPRA system, and the 
modems are arranged to provide a dial-in/dial- 
back protocol for security of access. Two mod¬ 
ems are configured as ‘dial-in’, while the 
remaining eight are configured as ‘dial-back’ to 
allow for the longer call holding times when 
down-loading data to the service providers. 

Access for TouchTone telephones is via adjunct 
processors—Caesar front-end processors 
(CFEPs)—which accept dual-tone multi-fre¬ 
quency (DTMF) signalling in response to spoken 
dialogues, automatically generated by the CFEPs. 
The service providers use the dialogue to request 
a particular spoken report from the particular 
CFEP. In addition to providing access for Touch- 
Tone telephones, the CFEP is also able to generate 
‘continuous audio feed’ announcements, which 
can be fed to other equipment (for example, RIDE) 



Figure 1 
Schematic of the 
DSN RIDE OPRA 
system 


DSN: Derived services network RIDE: Recorded information distribution equipment 

OPRA: Opinion poll registration application SUPPROC: Supervisory processor 

PSTN: Public switched telephone network 
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Figure 2 

Auxiliary switch 
OPRA configuration 


SERVICE 

PROVIDER 

PC 



DSN: Derived services network 
OPRA: Opinion poll registration application 


LAN: Local area network 
PSTN: Public switched telephone network 


and used as an MRIS announcement service. This 
announcement could be used to provide a ‘televote 
results’ service, when associated with the service 
provider’s summary services. Each CFEPcan pro¬ 
vide five lines, split between TouchTone telephone 
access and continuous audio feed. The DSN RIDE 
OPRA system uses three CFEPs giving 15 lines, 
while the auxiliary switch OPRA uses two CFEPs 
giving 10 lines, although either OPRA system can 
support up to a maximum of eight CFEPs. 

Both OPRA systems also provide administra¬ 
tion access via a common workstation-based 
OPRA system management unit (OSMU) and a 
printer. The OSMU also provides a mechanism for 
reporting exception conditions which may occur 
during day-to-day operation of the OPRA systems. 
Each OPRA processor has a system console to 
provide specialist access for maintenance pur¬ 
poses. A tape streamer (integral with the OPRA 
processor) is provided to allow operational person¬ 
nel to back-up statistics data on a regular basis. 

The following section briefly reviews the his¬ 
tory of OPRA developments, leading to the pres¬ 
ent systems. A more detailed description of the 
hardware and software architecture of the present 
systems is then given. 

HISTORY OF OPRA 

OPRA has evolved through two major software 
releases leading to the present systems. The first 


release provided a basic system and the sub¬ 
sequent releases have expanded the functionality 
of the system. 

First Release of OPRA 

The first release provided facilities for collecting 
call data from the DSN RIDEs installed at the 
recorded announcement centres (RACs), and 
provided data to service providers via PC access. 
A system for commissioning was delivered in 
December 1989 and the operational system was 
delivered to the NAC in February 1990. 

The first release of OPRA was provided on a 
UNIX-based PC, equipped with a 350 Mbyte hard 
disc, and a 60 Mbyte tape streamer for data back¬ 
up. The system also included separate terminals for 
administration access and exception reporting. 

In addition to the system for DSN RIDEs, the 
software developed for the first release was also 
used on a separate OPRA system to collect call 
data from RIDEs installed at DMSU sites. These 
RIDEs were used to provide recorded an¬ 
nouncements during the London code change, 
and the resulting statistics for calls to these an¬ 
nouncements were delivered by OPRA for ana¬ 
lysis within BT. 

Second Release of OPRA 

The second release, serving the DSN RIDE sys¬ 
tem, ran on the same computers as the earlier 
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release, and extended the earlier software to pro¬ 
vide the following additional facilities: 

• By using a TouchTone telephone, service pro¬ 
viders were able to obtain access to spoken sum¬ 
mary reports over the PSTN via CFEPs. Two 
CFEPs were used to provide up to 10 lines of 
access. 

# A ‘televote’ results announcement could be 
generated by the CFEP and fed into the RIDE 
distribution network. This facility, although to 
date not yet used commercially, allows the public 
to telephone the announcement and listen to the 
progress of the televote. 

® The data values from a number of RIDEs 
serving a geographical region could be aggre¬ 
gated to form single values. 

The OPRA processor was equipped with an 
Ethernet adapter board to communicate with the 
CFEPs, by using the TCP/IP protocol. 

The second release of OPRA went into service 
at the NAC in April 1991. 



DSN: Derived services network LAN: Local area network 

RIDE: Recorded information services OPRA: Opinion poll registration application 


Present Releases of OPRA 

DSN RIDE OPRA (Third Release) 

The third release of OPRA, available in May 
1992, is used for the DSN RIDE OPRA. The 
release runs on UNIX workstation-based compu¬ 
ters equipped with asynchronous communication 
ports and Ethernet adapters. In terms of software, 
the system extends the earlier releases to include: 


for the one-minute services. Also for the DSN Figure 3 
RIDE OPRA, an additional CFEP is used to pro- OPRA present 
vide extra lines to support the one-minute services. re,eases 
For both releases, the administration and ex¬ 
ception terminals are replaced by the OSMU, and 
this is illustrated by Figure 3, which shows a 
block diagram of the present systems, served by 
the common OSMU system. 

OPRA System Management Unit (OSMU) 


• configuration of RIDE communication paths, 
for the collection of data; 

• delivery of one-minute summary statistics for 
assigned announcement channels on the RIDEs; 
and 

• spoken reports from the CFEP which are con¬ 
tinuously updated as new data is collected during 
the call. 

Auxiliary Switch OPRA (Fourth Release) 

The fourth release of OPRA, available in mid- 
1992, is used for the auxiliary switch OPRA. As 
for the third release, UNIX workstation-based 
computers equipped with asynchronous com¬ 
munication ports and Ethernet adapters are used. 
Connection to the auxiliary switches is via Ether¬ 
net, in addition to the connection to the CFEPs. 
In terms of software, the system extends earlier 
releases to provide: 

• collection of data from the auxiliary switches, 
and 

• configuration of auxiliary switch communica¬ 
tions paths, for the collection of data. 


The OSMU provides: 

• an operator interface for controlling and ad¬ 
ministering the two OPRAs (the DSN RIDE 
OPRA and the auxiliary switch OPRA), which is 
achieved by two windows, each running a termi¬ 
nal emulator running the command menus and 
forms for an OPRA; and 

• a common window, in which is displayed the 
exception reports from each of the two OPRAs. 

The OSMU is connected to the OPRAs by an 
Ethernet using the TCP/IP protocol to communi¬ 
cate between the machines. 

OPRA HARDWARE 

The hardware for the present system can be con¬ 
sidered in four main areas: 

• OPRA processor, 

• OPRA system management unit, 

• CFEPs, and 

• modems. 

OPRA Processor 


The release supports the standard detailed and 
summary statistics services; it does not provide 
one-minute statistics. 

For both releases, the CFEP hardware remains 
unchanged, although the CFEP software is en¬ 
hanced. In particular, for the DSN RIDE OPRA, 
the CFEP supports dialogues and report generation 


The system computer is rack-mounted and con¬ 
sists of a Sun Sparcserver 2 with a Sun Sparc 2 
processor, 32 Mbyte random-access memory 
(RAM) and two 1*3 Gbyte mirrored discs. It is 
equipped with a 32-asynchronous-port Baydell 
Box, Ethernet interface card and runs the SunOS 
4.1.1 (UNIX) operating system. 
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Figure 4 

Software overview 


Security of data is provided by the use of 
mirrored discs (that is, data is written simulta¬ 
neously to two discs), and daily archiving of the 
database to tape. 

A stand-by OPRA is provided to which, in the 
event of failure, the database can be transferred, 
with a maximum of 1 day’s data lost. 

The stand-by OPRA can be used to retrieve 
archived service data that is older than 7 days 
from magnetic tape. 

OPRA System Management Unit (OSMU) 

The OSMU is a Sun Sparcstation IPC with 
12 Mbyte RAM, 200 Mbyte disc and colour moni¬ 
tor, and runs the SunOS 4.1.1 (UNIX) operating 
system. 

Caesar Front-End Processors (CFEPs) 

OPRA can connect up to eight CFEPs via Ether¬ 
net. Each CFEP consists of a 80386-based per¬ 
sonal computer. It is equipped with five BT 
speech cards, developed by the Speech Applica¬ 
tions Division at BT Laboratories, and an intelli¬ 
gent Ethernet card. The system runs the QNX 
2.1.5 operating system. 

Modems 

Each OPRA system is equipped with 10 modems. 
These are BT NS2232B modems which operate 
full duplex at line rates between 300 and 
14 400 bit/s, and provide the Hayes command set 
for controlling the operation of the modem. 


OPRA SOFTWARE 

The OPRA software for the present releases con¬ 
sists of several concurrently executing processes 
run under the UNIX operating system. Each pro¬ 
cess performs a separate task involved in the 
collection, management, and examination of the 
data. Figure 4 illustrates a highly simplified over¬ 
view of the functional software components and 
data stores contained within the OPRA software 
for the RIDE application. 

The application for the auxiliary switch has a 
similar functional architecture. 

The OPRA software is partitioned into the 
following functional components: 

Operator Intel face —provides the human in¬ 
terface to the OPRA system. 

Datel Intetface —enables service providers to 
obtain reports for their services via the PSTN on 
data communication lines equipped with modems. 

Customer Voice Intetface —enables service 
providers to obtain spoken reports on their ser¬ 
vices over the telephone. 

Report Generation —obtains service-provider 
reports from the database and reformats them 
into a form suitable for delivery. 

Database Management —provides the cus¬ 
tomer and service data, service history files and 
the various logs. 

RIDE Data Collection —collects the data 
from the control processes and processes it to 
produce the service history files. 

System Management —provides various fa¬ 
cilities for starting the OPRA system and control¬ 
ling its operation. 



CFEP: Caesar front-end processor 
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Operator Interface 

The operator interface provides a menu-driven 
command set: 

© to control the OPR A system and its communi¬ 
cation with other systems; 

• to enter data to define service providers, their 
services and the associated equipment channels 
used to provide announcements; and 

• to display or obtain printed reports. 

The external operator interface is provided by 
the OSMU, which functions as a multiple window 
display and is connected via the Ethernet LAN to 
a number of OPRAs. Each controlled OPRA has a 
separate window on the OSMU in which is run a 
terminal emulator (this replaces the separate oper¬ 
ator terminals required for the earlier OPRA re¬ 
leases). Exception reports from all of the 
controlled OPRAs are displayed in a common 
window, which replaces the separate exception 
terminals required for earlier OPRA releases. 

The operator interface software on OPRA 
uses a menu and windows style implemented by 
using the Panel Plus screen handling package. A 
typical menu screen displayed in an OSMU win¬ 
dow is shown in Figure 5. 

The operator selects commands from a list by 
using the cursor up/down keys to move to the 
required command option and keying return to 
invoke the command. Return to a higher level 
menu is obtained by using the ESCAPE key. 

Voice Interface 


—[ Sub-Menus 1 — 
USER MENU 
CUSTOMER MENU 
STATUS MENU 
NETUORK MENU 
SVSTEM MENU 
SEUERE MENU 
ABOUT OPRA 


Opinion Poll Registration Application 


—I Operator 1 
T ime 
Date 
Operator Nane 


— [ Messages 1 ■ — • — 
Tue Oct 16 14: 19:46 
Tue Oct 16 14:19:46 
Tue Oct 16 14:19:46 


r— [ Netuork Menu ]- 
Enable Polling 
Disable Po11ing 
Link Actions 
Voice Actions 
Call Point Configuration 



1990 * SVSTEM IS UP 
1990 »«»» » »««« »» « -»« 


I Status 1- 


Po11ing 
D1 MODEMS 
DB MODEMS 
DB Queue 
Printer 
Comnunication I 
Process Data : 


Disabled 
0 / 0 / 0 
0 / 0 / 0 
0 / 0 / 0 
Unknown 
Unknown 
Unknown 


tion process to send the latest report to voice Figure 5 

cards supplying spoken report services. Typical menu screen 

The mode of operation of a CFEP port is 
established by using the CFEP configuration 
operator commands. 

The CFEPs are connected to the OPRA via 
Ethernet by using the TCP/IP protocol and are 
handled by the voice-component software. The 
voice component consists of two processes: 

• the CFEP process , which controls the CFEPs 
as single units and its component voice cards, and 
handles requests from the CFEP voice cards aris¬ 
ing from requests for service reports; and 

# the Ethernet voice circuit , which handles all 
communication over the Ethernet circuits to the 
CFEPs in conjunction with the Ethernet com¬ 
munication process. 


The CFEPs enable service providers to obtain 
spoken summary reports and phone poll reports. 
The customer dials into OPRA and is connected 
to a free CFEP port. The CFEP prompts the 
customer to supply a 4-digit customer identity 
and a 6-digit PIN by using his/her telephone’s 
DTMF keypad to identify the service for which 
a report is required, and these are sent to OPRA. 
The PIN must identify a summary or one-minute 
service. 

If the customer’s identity number and the PIN 
are valid and correspond, a report is downloaded 
from OPRA to the CFEP. The caller, via spoken 
menu prompts, can obtain selected parts of sum¬ 
mary reports by keying appropriate TouchTone 
keys on his/her telephone. 

For one-minute reports, the report is contin¬ 
ually updated after each 1 minute collection peri¬ 
od and spoken for up to 20 minutes. On the 
completion of a one-minute data collection cycle, 
the RIDE data collection component sends a 
message to update voice cards handling one- 
minute reports. 

Facilities are also provided to enable the ser¬ 
vice providers to reset the count values for their 
services. 

The CFEP is also able to supply continous 
spoken reports that can be a service in their own 
right. At the completion of each data collection 
cycle, a message is received from the data collec- 


DATABASE MANAGEMENT 

Since the OPRA software consists of several con¬ 
current, communicating processes, and numerous 
shared databases, it is possible for two processes 
to be attempting to read from, or write to, the same 
database at the same time. This can result in cor¬ 
rupted data being read from, or written to, the disc. 
In order to prevent this, some form of database 
arbitration is required. The arbitration in the OPRA 
is provided by the database-manager process, 
which handles all requests for data and controls the 
processes which access the data. 

The database manager is implemented as a 
controlling process which decodes database ac¬ 
cess requests into simple commands directed to 
the server process which accesses the required 
logical data store. This allows simultaneous ac¬ 
cess to different data entities to enhance system 
disc performance, and allows the different data 
entities to reside on separate physical disc sub¬ 
systems to allow true concurrent disc accesses if 
required for speed. 

The server approach also hides the physical 
structure and format of the data from the users of 
the data. 

FUTURE DEVELOPMENTS 

The functionality of OPRA will be further en¬ 
hanced to match the needs of the MRIS service 
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offering. Already planned is the delivery of a 
third OPRA system to collect and deliver call 
statistics from the DMSU RIDEs. This system 
will use the functionality provided by the third 
release used for the DSN RIDE OPRA, and will 
be controlled for administration purposes by the 
OSMU system. Other enhancements are also 
planned; these could include increasing the total 
number of services handled by each OPRA from 
the current 2000 maximum, and providing one- 
minute statistics for all announcement services 
handled by OPRA. 
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fiVianageef Recorded Information Services— Control and 
Management 

ERIC ALLARD and DAVE WOODSt 


Several platforms are being developed that will contribute to the control and management of the 
managed recorded information services systems. The monitor alarm unit is a specialist system for 
monitoring announcement services, live feeds and other equipment in the managed recorded information 
sendees platform. The system management unit at the national announcement centre (NAC) provides a 
common platform for the management of recorded information distribution equipment (RIDE), the 
opinion poll registration application equipment and other systems. The NAC-RAC enhanced communi¬ 
cations network provides communications paths between the NAC and the recorded announcement 
centres (RACs) for relaying control and management data, and for conveying live-feed sendees. 


INTRODUCTION 

Three main developments are under way for the 
control and management of the managed re¬ 
corded information services platforms. These are 
described in this article. 

The monitor ala tin unit is a specialist system 
for monitoring and providing alarms for a number 
of aspects of the managed recorded information 
service platform. The alarm status information is 
displayed on personal computers (PCs) located at 
the national announcement centre (NAC). The 
monitor alarm unit is used to monitor services such 
as the recorded information distribution equip¬ 
ment (RIDE) announcements, live feeds, equip¬ 
ment failure and traffic overflow conditions. 

The system management unit , developed and 
designed at BT Laboratories, provides a manage¬ 
ment platform for RIDE, the opinion poll regis¬ 
tration application (OPRA) system and other 
applications. More details of RIDE and OPRA 
are provided in other articles in this issue of the 
Journal lf 2 . 

The communications network between the 
NAC and the eight recorded announcement cen¬ 
tres (RACs) carries control and management data 
(including that required for RIDE and OPRA) 
and has the capacity to allow several other com¬ 
munications systems to migrate onto the net¬ 
work. It also provides the distribution of live-feed 
services from the RACs to the NAC. 

MONITOR ALARM UNIT 

The monitor alarm unit provides four basic func¬ 
tions: 

• monitoring of audio announcements; 

• monitoring of live-feed services; 

• monitoring of equipment alarms; and 

• monitoring of traffic overflow conditions. 

The monitor alarm unit is managed by a net¬ 
work of master and slave PCs, which provide 
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displays of alarm conditions and enable remote 
call-out and interrogation by maintenance per¬ 
sonnel for out-of-normal-hours working. 

Each RAC and the NAC has a master PC which 
is responsible for servicing and monitoring for that 
centre. Each master PC may be connected to a 
local slave PC and, via a modem, to a portable PC, 
which may be earned by the engineer on call. The 
NAC has, additionally, a singleton alarm for each 
RAC. The operator at the NAC can dial from a 
single PC into any of the RACs to obtain more 
information. This method of access is protected by 
password control. 

As shown in Figure 1, the monitor alarm unit 
at each site physically comprises five 19 inch 
shelves in a cabinet, a master PC and printer, a 
slave PC, a modem link and the associated 


PORTABLE 

PERSONAL 


CABINET C0MPUTER 



Figure 1 

Monitor alarm unit 

hardware 

configuration 
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cables. Each shelf can contain a MUX/power 
card and up to 15 other cards, or up to 12 cards if 
an exchange control unit is fitted. The cards are 
arranged in modules of three cards, each module 
containing one central processor unit (CPU) card 
and two line interface cards. 

The monitor alarm unit is designed to operate 
in a normal public telecommunications environ¬ 
ment. 

The connection of the monitor alarm unit sys¬ 
tem to work in this environment is illustrated by 
Figure 2. 

The functionality of the monitor alarm unit is 
provided by three main types of line interface 
card. These are described in the following sec¬ 
tions. 

Line Interface Monitor-Type 1 

The Type 1 card is used to monitor announcement 
services. If an announcement service is not de¬ 
tected, the card raises an alarm. 

Each card provides monitors for eight audio 
announcement channels. 

Each channel monitor checks for ‘silence’ on 
the channel, and the card generates an alarm 
when the level of audio activity is below a set 
level. There are various different types of 
‘silence’; for example, a pause in speech, the gap 
between the end of one message and the message 
being repeated, and that caused by a fault. It is 
p. re 2 only the latter that generates an alarm. When the 

Monitor alarm unit card detects non-activity on a circuit, it begins 

connection details counting seconds. If the count reaches a preset 


VIEWED FROM REAR 



DISTRIBUTION ALARMS 

FRAME 


ECU: Exchange control unit 


threshold, normally set at 60 s, it generates an 
alarm. 

The Type 1 card is configurable to detect 
activity on the circuits above audio signal levels 
of -20 dBm or -30 dBm. 

Line Interface Monitor—Type 2 

The Type 2 card is a change-over switch which 
is used to monitor live feeds. 

The live-feed network provides two feeds, a 
primary feed and a secondary feed. These are 
generally transmitted over different paths for se¬ 
curity. 

The Type 2 card normally switches the pri¬ 
mary feed for onward distribution to announce¬ 
ment equipment. It continuously monitors the 
primary feed for audio activity, and, in the event 
of failure of this feed, it switches to the secondary 
feed and uses this for onward distribution. 

The card remains switched to the secondary 
feed until it is manually switched back to the 
primary feed. On switching to the secondary 
route, an alarm is produced indicating that the 
primary route is ‘silent’. 

If the secondary route fails before the primary 
route has been repaired, the card switches to 
another back-up line, connected to a local an¬ 
nouncement source which could replay a courte¬ 
sy message. 

One Type 2 card is required per set of feeds. 

Line Interface Monitor—Type 3 

The main function of the Type 3 card is to provide 
feed and monitor circuitry for seven alarm relays 
connected to external equipment. In addition, it 
has the capability of monitoring traffic overflow 
conditions. 

Other Equipment 

In addition to the three cards described above, the 
monitor alarm unit comprises a number of other 
items of equipment. 

The line interface monitor CPU card contains 
the CPU and random-access memory for control 
cards 1 -3 inclusive. One CPU card is required for 
each pair of monitor cards. The CPU card con¬ 
tains a rechargeable battery to support memory 
for up to four days if the power is disconnected. 

Each line interface shelf contains a single 
MUX/power card to provide power at 5 V DC to 
the line modules, the card/CPU selection logic, 
and a communications link with the exchange 
control unit. The exchange control unit enables 
the user to communicate with up to five shelves. 
A loudspeaker on the front panel allows the oper¬ 
ator to listen to the lines in use. A speaker jack is 
also provided for switching the sound to a separ¬ 
ate room, if required. 

Within each monitor alarm unit, the upper 
four shelves can contain up to five modules of 
three cards, and the bottom shelf can hold the 
exchange control unit and up to four modules. 
This modular construction provides economic 
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expansion and flexibility, where a complete mo¬ 
dule of two line interface cards and one CPU card 
will serve up to 16 terminations (two Type 1 cards 
installed) or a sub-equipped module with only 
one line interface card and one CPU card will 
support up to eight lines (Type 1 card installed). 
Each exchange control unit can support a maxi¬ 
mum of five fully-equipped shelves. 

Monitor Alarm Unit Management 

During normal working hours, the monitor alarm 
unit provides both visual and audio alarms via the 
PCs in use. However, for out-of-hours working, 
the monitor alarm unit also has the capability to 
page maintenance personnel. In the event of an 
out-of-hours alarm being raised, the master PC 
can dial up to six preprogrammed numbers in 
turn until the fault receives attention. The main¬ 
tenance officer who is on-call can use a portable 
PC and dial directly into the system, by using a 
modem, and obtain the same display on the port¬ 
able as is on the master PC. Thus, any fault can 
be investigated immediately and a decision made 
as to whether to clear the alarms and deal with 
the problem the next day, or to investigate the 
problem immediately. 

A man-machine interface (MMI) is pro¬ 
vided by the two PCs at each site. The master 
PC provides the user with the main configura¬ 
tion and control point for the whole system. 
With the MMI, the user can configure the sys¬ 
tem, monitor line activity, monitor alarms, ac¬ 
knowledge alarms, check hardware 
configuration and manually switch to back-up 
lines. 

Three additional cards are also fitted in the 
PCs, two of these are internal modem cards and 
the other is a card to allow mouse operation. 


SYSTEM MANAGEMENT UNIT 

The system management unit is located at the 
NAC and, as part of its first application, it is being 
used to manage the DSN RIDEs and the digital 
main switching unit (DMSU) RIDEs from a cen¬ 
tral point. 

Initially, the DSN and DMSU RIDEs were 
managed by using a number of recorded informa¬ 
tion services control processors 1 , which are PC- 
based machines, running RIDE management 
software. The operational need to reduce the 
volume and complexity of operating a large num¬ 
ber of such processors had led to the rationalised 
approach of providing the system management 
unit to allow management of the RIDEs from a 
smaller number of workstations. 

The need to rationalise equipment also led to 
the development of a management workstation 
for OPRA administration, replacing the separ¬ 
ate terminals needed to manage the OPRA sys¬ 
tems used with RIDE and the auxiliary 
switches. 

The OPRA management workstation forms 
part of the system management unit, although its 
function is separate to that provided for RIDE 
management. OPRA is described more fully else¬ 
where in this issue of the Journal 2 . 

The system management unit is provided as a 
local area network (LAN)-based platform using 
Ethernet. This allows the interconnection of pro¬ 
cessors running specific applications, worksta¬ 
tions for operator access, databases, and the 
connection to the RACs via the NAC-RAC 
wide-area network (WAN). Although initially 
developed for the RIDE and OPRA applications, 
the system management unit will be used for 
other managed recorded information service ap¬ 
plications. 


Man-Machine Interface 

The MMI function is divided between the master 
and secondary PCs. The information required is 
displayed on the visual display unit (VDU) and 
can be printed on command. The MMI is control¬ 
led by means of the PC keyboard and mouse. The 
operator options are given on pull-down menus 
on the VDU and selections can be made by using 
either the keyboard or the mouse. An example of 
an MMI display is shown in Figure 3. In this 
display, the upper SYSTEM box displays informa¬ 
tion about the operation of the MMI; that is, the 
log-in details after the operator has logged in; the 
shelf number, module number, card number and 
line number currently being monitored by the 
MMI; or the voice monitor condition when the 
operator turns the voice monitor ON or OFF. 

The box below this displays the status code, 
in matrix form, of each line associated with the 
cards in the current shelf, displaying up to five 
modules of three cards each per shelf. The bottom 
line of the matrix is the card line. The operator 
can configure individual lines and cards from the 
card/line matrix. 


RIDE System Management Unit 

Figure 3 

The RIDE system management unit is designed Monitor alarm unit 
to manage all RIDEs in the network. To ease display 
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operations, the RIDEs are grouped into logical 
systems, dependent on the distribution network 
to which they are connected. There is one sys¬ 
tem for DSN RIDEs, and three systems for 
DMSU RIDEs. Any one system can be control¬ 
led from the system management unit by the 
operator establishing a session with the particu¬ 
lar system. 

For each RIDE system, the RIDE system man¬ 
agement unit application: 

• gathers and displays RIDE alarm information 
every 30 s, 

0 allows user interrogation and control of indi¬ 
vidual RIDEs, and 

© collects, every minute, call statistics gener¬ 
ated by RIDEs. 

The RIDE system management unit is de¬ 
signed to manage up to a total of 170 RIDEs, 
grouped in up to ten systems, although currently 
there are 82 RIDEs (at DSN and DMSU sites) 
grouped in four systems. 

Figure 4 shows a block diagram of the system 
management unit hardware that is provided at the 
NAC. The human interface processors are SUN 
workstations, which are connected to the RIDE 
control processor (a SUN workstation server) via 
an Ethernet LAN. The RIDE control processor, 
in turn, is connected to the RIDE interface pro¬ 
cessors (which are reused recorded information 
services control processors with appropriate 
modifications to the existing software). Two 
human interface processors are normally used, 
although up to four can be used. There is a single 
RIDE control processor and eight RIDE interface 
processors, but up to 17 can be used to provide 
connections to 170 RIDEs. 



RIDE: Recorded information distribution equipment 


The RIDE control processor runs the RIDE 
management application and performs the fol¬ 
lowing functions: 

# provides an interface to the human interface 
processors, 

® provides an interface to the RIDE interface 
processors, 

• acts as a communications concentration point 
for both the human and RIDE interface processors, 


• controls access to RIDE systems from the 
human interface processors, 

© processes user requests/responses (entered 
via the human interface processor), 

• maintains a record of the current alarms on all 
RIDE sites, 

0 maintains a record of the current call restric¬ 
tions on all RIDE sites, and 
0 stores and controls access to the current con¬ 
figuration of RIDE systems and RIDEs. 

The RIDE control processor does not require 
a keyboard or screen. Connection to the RIDE 
interface processors for the passing of control 
signals and for receiving status information is by 
an asynchronous bidirectional RS232 link to 
each processor. 

The connection to the human interface proces¬ 
sor is provided by the Ethernet LAN. 

The RIDE interface processor performs the 
following functions: 

0 provides an interface to the RIDE control 
processor, 

• provides an interface to the RIDE nodes, 

• provides an interface to OPRA for statistics 
gathering, 

• schedules the polling of RIDEs for alarm and 
statistics information, 

© acts as a communications concentration point, 
and 

© provides a connection to the external alarm 
scheme. 

Connection of a RIDE interface processor to 
each RIDE for the transfer of system management 
messages (commands, alarm information, call 
statistics information) is by an asynchronous bidi¬ 
rectional RS232 link. For DSN RIDE communi¬ 
cations this connection is made via a terminal 
server connected to the LAN and the NAC-RAC 
WAN. The RIDE interface processor also has a 
connection to the OPRA processor and the RIDE 
control processor, using bidirectional RS232 links. 

To interface to the NAC alarm scheme, addi¬ 
tional cards are provided within the RIDE inter¬ 
face processors. These cards have a relay contact 
that is controlled by software and can raise an 
alarm as part of the NAC alarm scheme. The 
relay contact is used to signal a call-out alarm, 
either by a message from the RIDE control pro¬ 
cessor or by the failure of power to the RIDE 
interface processor. 

The human interface processor is a SUN work¬ 
station with a keyboard, mouse and a colour 
monitor. It provides the following functions: 

© a human interface using a window-icon- 
mouse-pointer interface; 

© multiple windows on screen; 

• password access for security; and 
© all audible alarm indications. 

Alarms 

Alarms generated by the RIDEs are collected by 
the RIDE interface processors every 30 s and 
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passed to the RIDE control processor for further 
processing. The RIDE control processor imple¬ 
ments four levels of alarms: 

• raw alarms; 

© level 1 alarms; 

<i level 2 alarms; and 
& call-out alarms. 

Raw alarms are the individual alarm condi¬ 
tions reported on the RIDE 1 . 

Every raw alarm causes one or more level 1 
alarms and, where appropriate, the level 1 alarms 
group together raw alarms to rationalise and re¬ 
duce the amount of alarm information that is 
presented to the operator. 

The RIDE system level 1 alarms are formed 
into five groups which focus on the different 
objects within the RIDE that are being managed, 
namely: 

• communications, 

• the interface to the RIDE distribution net¬ 
work, 

• the public exchange interface (DSN or 
DMSU), 

• the start-at-the-beginning announcement 1 
availability, and 

• equipment (that is, processor) status within 
RIDE. 

For each group of level 1 alarms there is a 
level 2 alarm, giving the five level 2 alarms per 
RIDE. The level 2 alarm is activated when certain 
level 1 alarms or combinations of level 1 alarms 
within the group are active. The criterion used for 
selecting the requirement for a level 2 alarm is ‘a 
condition which requires urgent attention’. 

In addition to the five level 2 alarms per RIDE, 
there is a level 2 alarm which relates to the RIDE 
control processor and the RIDE interface proces¬ 
sors, and this also represents ‘a condition which 
requires urgent attention’. 

The fourth alarm type is the call-out alarm. 
There is one call-out alarm per RIDE plus one for 
the RIDE control processor/RIDE interface pro¬ 
cessors. It is triggered by any one of a number of 
pre-defined conditions, which may be specific 
level 1 alarms or combinations of level 1 alarms. 

For general operation, two of these four 
alarms are used, the level 1 and level 2 alarms. 
However, it is possible to retrieve information on 
raw alarms by means of further interrogation. 
The call-out alarm is primarily used for determin¬ 
ing if assistance is required during out-of-hours 
periods. Conditions causing a call-out alarm also 
cause a level 2 alarm; the converse is not necess¬ 
arily true. 

Operation 

During operation, the operator is presented with 
high-level information on all of the applications 
being supported by the system management unit. 
The operator’s screen has a RIDE control appli¬ 
cation window plus windows for general service 
applications. The service applications appeal* at 



One window per RIDE One window for the 

system, to a maximum of three ride control application 


RIDE: Recorded information distribution equipment 
RIS: Recorded information service 
SAB: Start-at-the-beginning 

the bottom of the screen and are visible at all Figure 5 
tj mes Human interface 

By using a mouse, it is possible for an operator >vindow hierarchy 

to interrogate and control any RIDE system 
through the selection of the appropriate com¬ 
mands. The operator can have control of a maxi¬ 
mum of three RIDE systems simultaneously 
from any human interface processor, with no 
more than one processor in control of a particular 
RIDE system at any one time. The status of the 
RIDE systems is shown to the operator by using 
alarm indications, call restriction records and 
configuration tables. Warnings are given to the 
operator of the potentially serious effect of some 
actions. 

A hierarchy of windows is used to present the 
large amount of alarms, call restrictions and con¬ 
figuration information and to enable interroga¬ 
tion and control of the RIDEs. The level of detail 
presented increases as the operator moves lower 
in the hierarchy. Other windows outside this hier¬ 
archy can be used as necessary. Six window types 
are used, as shown in Figure 5. 

Within the window hierarchy, the highest- 
level window presents an overview of the RIDE 
systems, while the second-level window presents 
a RIDE system as a number of RIDEs (up to 32) 
and provides interrogation and control facilities 
that apply to the whole RIDE system. 

At the lowest level, there are two window types: 
the RIDE window and the RIDE control unit 
(RIDE control processor/RIDE interface proces¬ 
sors) alarms window. The RIDE window presents 
data relating to an individual RIDE location and 
provides interrogation and control facilities that 
are limited to a single RIDE in scope. There are 
seven variations of this window for each RIDE 
showing different alarms, call restrictions or con¬ 
figuration information. The RIDE control unit 
alarms window presents and manages alarms data 
specific to the RIDE control unit. 


46 


British Telecommunications Engineering, Vol. 11, April 1992 






















































Software Architecture 

The RIDE control unit software is spread across 
three sites: the human interface processor, the 
RIDE control processor and the RIDE interface 
processor. There are defined interfaces between 
sites and between processes on each site. The 
software architecture is divided first into func¬ 
tions—related activities which involve all rele¬ 
vant processing sites; and then processes—the 
implementation of a function on a particular pro¬ 
cessing site. 

The functions implemented include: 

© alarms handling; 

© user request handling; 

© call restrictions; 

Q message handling and RIDE interface proces¬ 
sor link handling; and 
Q dynamic parameter table downloading. 

Dynamic Parameter Tables 

Within RIDE, call progression is controlled by 
data held in a parameter table 1 . This data typically 
provides the translation from dialled-digit infor¬ 
mation received by RIDE from the exchange to the 
required announcement service to be connected by 
the RIDE. Other data controls other parameters 
(for example, whether a start-at-beginning an¬ 
nouncement shall be played or not). 

The current table is fixed, but the system 
management unit development provides a 
dynamic means of updating the tables. 

The parameter table is built and processed 
off-line by using an ORACLE™ database appli¬ 
cation, running as an application on the system 
management unit. The database allows the cre¬ 
ation and editing of service-type templates that 
define the phases of a call. 

New tables are created by defining service 
instances using the service-type templates and 
adding details of the recorded information ser¬ 
vices used for the announcements. Alternatively, 
new tables can be created by copying and editing 
existing tables. The resulting table is checked by 
generating and examining reports of the usage of 
recorded information services and digit combi¬ 
nations. When the parameter table has been pro¬ 
cessed, the data is generated in a file. Under 
command from the operator, the RIDE control 
processor can read the file and download the data 
to parameter tables held in RIDE. 

At each RIDE site, the information is stored 
in a number of tables known as alternative tables , 
while calls continue to be connected using infor¬ 
mation held in a corresponding number of cur¬ 
rent tables. 

The operator can download a table to one or 
all RIDEs in a system by executing the appropri¬ 
ate command at the RIDE or system level. The 
command prompts for the name of the file to be 
downloaded, which is then read and checked. If 
the file cannot be found or is of the wrong format, 
then the operator is informed and the command 
is aborted. 


If a valid file is found, the download is started 
and control is returned to the operator while 
downloading continues in the background. While 
the download is in progress, the operator cannot 
release control of the RIDE system, but further 
commands, excluding parameter table com¬ 
mands, can be executed on that system. The 
operator can also take control of another RIDE 
system and can initiate a download to that system 
while the first download continues. 

Progress of the download operation is indi¬ 
cated to the operator and any errors are reported 
as they occur. Re-tries are used where there are 
communications problems with a RIDE. If re¬ 
quired, the operator can abort a download to a 
system and take corrective action. When com¬ 
plete, the success of the download operation is 
reported, indicating any cases where a valid table 
is not held. The operator must acknowledge com¬ 
pletion of the download before continuing with 
further parameter table commands. If necessary, 
the download command can be repeated before 
the table is committed. 

Upon completion of a download, the operator 
is informed of the success of the operation. A 
separate verify command is also provided to 
allow the operator to verify subsequently that the 
required parameter table is still available for use 
on each RIDE. 

When the operator is satisfied that a valid 
alternative table is available, and is ready to 
change over to the new table, a COMMIT com¬ 
mand can be executed. The current table 
becomes the alternative table and all new calls 
use the new current table. The change-over can 
be reversed by executing the command with the 
filename of the previous table. 

ENHANCED NAC-RAC 
COMMUNICATIONS NETWORK 

The NAC-RAC communications network con¬ 
sists of dedicated 2 Mbit/s links terminated by 
primary-order multiplexers (PMUXs), connect¬ 
ing the eight RACs to the central NAC. 

The network was initially installed to provide 
duplicate connections for live-feed services from 
the RACs to the NAC, for onwards distribution 
by RIDE. This arrangement allows speedy live- 
feed provision, reducing service provider costs, 
since the only private wire needed is that from 
the service provider to the RAC. 

The topology of the communications network 
is shown in Figure 6. The eight routes between 
the individual RACs and the NAC are in the form 
of a star, with four additional routes added to 
form a delta configuration between paired RACs. 
This method provides for security of trans¬ 
mission of the duplicated line feeds. The primary 
feed is fed directly from an RAC to the NAC, 
with the secondary security routes provided via 
the paired RAC. 

The introduction of the auxiliary switch 
OPR A 2 saw the need to transmit large amounts 
of data between the RACs and NAC. To satisfy 
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this need, the communications network has been 
enhanced to allow not only the secure trans¬ 
mission of live-feed services, but also to provide 
a network for the transmission of data and control 
and management information for OPRA and 
DSN RIDE. The enhancement also allows other 
services to use the capacity of the network. 

The enhanced network is shown in Figure 7. 
The enhancements to the network involved re¬ 
placing the standard PMUXs associated with the 
2 Mbit/s links with intelligent MUXs. The intel¬ 
ligent MUXs connect to LAN bridges at the NAC 
and RAC which in turn allow connection of the 
LANs at the NAC and RAC forming a WAN. The 
WAN is used to carry the data for RIDE and 
OPRA. Live-feed connections are provided by 
direct connections to the intelligent MUXs. 

Intelligent MUXs 

An intelligent MUX is provided at each RAC site 
and eight, one for each link to the RACs, are 
provided at the NAC. Each MUX provides the 
following interfaces: 

# analogue 2/4 wire; 

% X.21 data; and 

# 2 Mbit/s. 

The analogue 2/4 wire interfaces provide the 
connections for the analogue live-feed services 
for transmission from the RAC to the NAC. 

The X.21 data interfaces provide the connec¬ 
tion to the LAN bridges to form the WAN. 

The 2 Mbit/s interfaces provide the connec¬ 
tion to the physical 2 Mbit/s links forming the 
transmission paths for the network. 

Control of the intelligent MUXs is per¬ 
formed by a network manager function pro¬ 
vided at the NAC. The network manager 
function is currently provided as an application 
on a PC which connects to the intelligent MUXs 
at the NAC (see Figure 7). A later version of the 
network manager function will run as an appli¬ 
cation on the system management unit platform 
at the NAC. From the network manager func¬ 
tion, an operator is able to configure routes used 
by the network by modifying data held in each 
of the MUXs. This configuration includes the 
presetting of alternative paths should a primary 
link fail. The network manager function is also 
able to monitor the status of the MUXs and 
report alarm information. 

Once configuration data has been extended into 
the system, the resilience of the network is control¬ 
led automatically by the MUXs. If the main pri¬ 
mary link between an RAC and the NAC fails, the 
MUXs automatically switch the required live feed 
and data channels to use the alternative path pro¬ 
vided via the adjacent RAC route. 

Wide Area Network 

The LAN bridges are provided to interconnect 
the RAC-based LANs and the NAC-based LAN 



NAC: National announcement centre RAC: Recorded announcement centre 


together to form the WAN. Interconnection of the 
bridges is provided by the X.21 interfaces on the 
intelligent MUXs, providing a semi-permanent 
128 kbit/s data channel between each of the brid¬ 
ges. 

Resilience of the data paths is provided by the 
security of the communications network, but ad¬ 
ditionally, the bridges are able to communicate 
and operate their own rerouting mechanisms if 
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necessary. Management of the WAN is provided 
by an application on the system management 
unit. This management application is able to 
communicate with all LAN bridges in the system 
and is able to display status information, includ¬ 
ing bridges or interconnecting links that may 
have failed. 
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Applications Using the 
Communications Network 

Initially, the communications network will be 
used to provide connections for DSN RIDE man¬ 
agement applications, auxiliary switch OPRA 
data and live feeds. Future applications will in¬ 
clude: 

• bulk data transfer from RAC to NAC, 

• customer-controlled data, 

• DMSU RIDE communications, 

• electronic mail, 

• remote control from NAC to RAC, 

• remote display of major events information, 
and 

• managed answering service database. 
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Managed Recorded Information) Services— Project 
Planning and Installation 

BILLMARTINELLI, and KEVIN BOSHERt 


This article describes the planning and installation of various aspects of the managed recorded 
information sendees , together with the project management processes used. 


INTRODUCTION 


Design and Development 


The market for managed recorded information 
services (MRIS) is both specialised and highly 
competitive. Owing to the nature of this market, 
BT has to be highly responsive to meet the re¬ 
quirements of its MRIS customers. In order to 
meet this challenge, the small teams of experts 
from the product line, BT Laboratories, network 
operations, technical support, project manage¬ 
ment and planning and maintenance, work close¬ 
ly together. This close cooperation requires an 
efficient project management framework; this 
article describes the processes used. 

PROJECT LIFE CYCLE 

Figure 1 is a simplified flow chart of the various 
processes an MRIS product development under¬ 
goes from conception to roll-out. 

The product line is responsible for identifying 
new markets for BT and potential new products. 
Because of the short time-scales that are necess¬ 
ary, a number of processes have to occur simul¬ 
taneously to ensure that all aspects of the 
development are installed and ready for network 
roll-out. 

Once a market opportunity has been identi¬ 
fied, the appropriate product line produces a 
client requirements definition for the new feature 
or application which forms the basis for a feasi¬ 
bility study. 

Feasibility 

During the feasibility process, all potential net¬ 
work solutions are investigated, with input from 
the MRIS teams, as appropriate. Among those 
consulted on the various aspects of the develop¬ 
ment are BT Laboratories and BT Worldwide 
Networks (technical support, planning, mainten¬ 
ance and operations). Information on full life¬ 
time costs is obtained together with possible 
time-scales for development and installation. 

The feasibility process delivers an agreed sol¬ 
ution, defining the technical deliverables, time- 
scales and associated costs. This information is 
used to prepare a business case to obtain the 
necessary authority to implement the solution. 


t BT Worldwide Networks 


After the feasibility process, there are two 
possible paths depending on whether there is a 
development required, or whether existing 
equipment is to be used. 

A new development could be for a specific 
piece of equipment, requiring project manage¬ 
ment of the development and planning of the 
environment to accommodate the new equip¬ 
ment. If the new equipment is a network-based 
solution, additional project management and 
planning are required to provide the network 
aspects. This could include, for example, the 
planning and installation of transmission routes. 

If the project uses existing equipment, it goes 
straight to the planning stage; however, if it re¬ 
quires new equipment (in its broadest sense) the 
project management process is used. The project 
manager appointed uses the resources of the 
same groups who advised in the feasibility pro¬ 
cess. This ensures that the same experts are in¬ 
volved throughout the life of a project to ensure Figure 1 
consistency of information and continuation of Product development 
knowledge. processes 
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BT Laboratories develops most of the equip¬ 
ment for the specialised MRIS platforms, but it 
also uses external contractors who can supply 
off-the-shelf solutions to meet the product re¬ 
quirements. In these cases, BT Laboratories is 
responsible for ensuring that the external con¬ 
tractors and the equipment they supply meetBT’s 
required specifications. Occasionally, the pro¬ 
duct required is a combination of an external 
contractor’s product and a BT Laboratories de¬ 
velopment, where BT Laboratories enhances the 
supplied product. BT Laboratories acts as an 
agent in negotiations with external contractors 
for the development. 


Planning 

While BT Laboratories is negotiating with the 
external contractors, or developing the equip¬ 
ment, planning within BT is already taking place. 
This ensures that all site work, cabling require¬ 
ments and so on are being planned and will be 
installed ready for the roll-out of the product. The 
planning manager has to provide information to 
Figure 2 the appropriate zones on such topics as the ac- 

MRIS project commodation required, the power required, ven- 

management process tilation required, time-scales, and so on. This 


CLIENT 



HAND OVER 


information is provided through network plan¬ 
ning guides. 

In addition, extra equipment may have to be 
centrally ordered for the zones. Lead times may 
be critical, as all the necessary extra equipment 
must be ordered, received, installed and tested 
before the new development is rolled out to en¬ 
sure that the delivery date is met. All develop¬ 
ment of equipment is the responsibility of the 
project manager. 

For the case where existing equipment is added, 
and no upgrades or new products are required, the 
process is simplified, with the planning manager 
investigating the existing capacity, obtaining fore¬ 
casts from the product line and usage figures from 
operations. This ensures that capacity is provided 
and that the operators are informed of the changes 
to the existing equipment. 

PROJECT MANAGEMENT 

Two aspects make MRIS different from other 
projects. Firstly, the time-scales involved can be 
very short, for example, only six months from 
inception to roll-out, with very little float and 
most activities being critical. Secondly, MRIS is 
a continuous programme and several projects are 
always in progress at any one time using the same 
people. 

Figure 2 shows a simplified block diagram of 
the project management process. 

The client requirements definition is produced 
by the appropriate product line for the new fea¬ 
ture or application and is subject to the feasibility 
process which, as explained earlier, uses the input 
from various groups within BT to determine 
whether the proposal is viable. From this process, 
a feasibility project requirements definition is 
produced which details the potential technical 
solution, expected costs and time-scales. 

Once a project has been deemed viable, a 
project manager is appointed who produces a 
project plan and obtains agreement for the use of 
resources required. A project requirements de¬ 
finition is written, which defines how the pro¬ 
duct-line requirements are to be met and the 
project time-scales. This is returned to the appro¬ 
priate product line who prepare a business case. 

The business case is a document that describes 
what needs to be done, the capital cost of the 
whole project and, specifically, the costs to 
Worldwide Networks, the expected payback 
period and the benefits to BT. This process en¬ 
ables the necessary financial authority and fund¬ 
ing to be obtained. The project manager provides 
a supporting paper to the product-line business 
case confirming that the required resources are 
available and that the end dates can be met. 

Once financial authority has been obtained, 
the project goes into development, with all tasks 
being coordinated by the project manager. 

Tenders are invited from, and eventually con¬ 
tracts are placed with, the relevant external sup¬ 
pliers, in-house development by BT Laboratories 
is commissioned, and installation work is planned. 
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Network planning guides are written and 
passed to the various zones for implementation, 
along with the generic acceptance testing, the 
acceptance testing statement of requirements, in¬ 
stallation guides, and operational guides. De¬ 
pending on the project these can either be new 
documents or additions and amendments to pre¬ 
viously published documents. Operation support 
and network management procedures are agreed 
and distributed. 

PROJECT PLANNING 

In order to ensure that the various parallel acti¬ 
vities operate successfully, the planning manager 
has to take a strategic overview of the whole 
process, taking into consideration possible future 
projects and other simultaneous projects. 

The planning manager has to compile strategic 
information such as the equipment required and its 
attributes: physical size, weight, power require¬ 
ments, footprint size, connections, venting, envi¬ 
ronmental considerations, and so on. 

This information is collated in a Network 
Planning Guide (NPG) and issued to all zone 
planners to enable them to ensure that they can 
meet all the accommodation requirements. They 
also use this information to schedule work pro¬ 
grammes. 

The planning manager will also have forecasts 
for the new equipment; that is, whether it will have 
any spare capacity, or whether further equipment 
is required to complement the development. 

In addition, new pieces of equipment, should 
they be required, are identified and ordered. 

Installing and Testing 

The generic acceptance testing is carried out on 
the first delivery and is usually done at BT La¬ 
boratories. The first product from the external 
contractor is thoroughly tested in all aspects of 
its design, quality, construction and functionality. 
Once it has passed all the tests satisfactorily, 
generic acceptance is granted and the product is 
rolled out to the zones. 

A number of the agreements with the external 
suppliers are ‘supply and install’ contracts, so it 
is the external contractors who install the equip¬ 
ment in the zones during roll-out. This will be 
under the supervision of the project manager. 

Occasionally, the zones are advised to order 
equipment themselves, rather than having the 
items ordered via the planning manager. These 
details are provided in the Network Planning 
Guides. 

Once installed in the zones, a site acceptance 
test is performed on the products. This is a func¬ 
tional test and does not repeat all the tests carried 
out in the generic acceptance tests. This is fol¬ 
lowed by the operational readiness test, which is 
basically a network trial, ensuring that the proce¬ 
dures and developments operate correctly. All the 
procedures are verified including fault reporting, 


fault escalation, billing, and so on, and when this 
has been satisfactorily completed, the project 
manager obtains operational sign-off and the pro¬ 
ject is finished. 

SUMMARY 

This article has described the important role of 
project planning and installation in ensuring that 
the MRIS platform is delivered. The tasks in¬ 
volved are varied with demands to plan, manage 
and install new developments which may be single 
items of equipment or network-based solutions, or 
enhancements to the existing platform. Of para¬ 
mount importance is the need for clear procedures 
to ensure that projects move efficiently through 
their life cycles from conception to roll-out. 
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Managed Recorded information Services — Customer 
interface Processes 

JOAN STEWARTj 


Robust processes are essential to ensure the success of any product in a competitive market-place. BT 
has offered information sendees since 1986 and the current processes have evolved in response to the 
need to provide customers with quality sendees. This article provides an ovendew of the support 
functions , processes and procedures associated with the provision of service for the managed recorded 
information sendees portfolio. All network provision is discussed in an accompanying article ! . 


INTRODUCTION 

BT is a world leader in the information services 
arena and, as such, has been proactive in facili¬ 
tating entry into this market by the introduction 
of a managed recorded information services 
(MRIS) portfolio. Details of the features and 
facilities offered to customers, usually referred to 
as sendee providers , can be found in another 
article in this issue of the Journal 2 . 

In a fast-moving, competitive environment 
such as the information services market, custo¬ 
mers demand a high standard of service. In order 
to satisfy these demands, BT has created a spe¬ 
cialist sales group and a customer service centre 
to support both Callstream and LinkLine™ pro¬ 
ducts, which together provide the necessary 
knowledge and expertise to enable customers’ 
needs to be realised by the most efficient and 
cost-effective methods. 

PRODUCT SUPPORT 

The MRIS support structure consists of several 
departments and systems, each of which interact 
to ensure that both service providers and calling 
customers receive prompt and efficient service. 
These are: 

• the Independent Committee for the Supervi¬ 
sion of Standards of Telephone Information Ser- 
vices (ICSTIS) 3 , 

• Connections in Business, 

• specialist sales, 

• customer service centre, and 

• the derived services network off-line support 
system. 

ICSTIS 


vices should comply. Service providers contract¬ 
ing for Callstream service are bound by BT’s 
terms and conditions to observe and adhere to this 
code of practice. 

The ICSTIS terms of reference are: 

® to set standards for the content and promotion 
of premium-rate telephone services and to keep 
such standards under review, 

• to consult the industry and other interested 
parties prior to changing these standards, 

• to monitor such services to ensure that both 
the content and promotional material comply 
with these standards, 

® to investigate complaints relating to the con¬ 
tent and the promotion of premium-rate tele¬ 
phone services and to recommend measures to 
achieve compliance where the code of practice 
has been breached, 

• to provide a system for the adjudication of 
claims for compensation in respect of unauth¬ 
orised use of live conversation services, 

• to publish reports on the work of the Commit¬ 
tee and adjudication of claims at regular inter¬ 
vals, and 

• to make sure its work is known and under¬ 
stood by the public, network operators and ser¬ 
vice providers. 

BT Connections in Business 

Connections in Business is a BT-owned tele¬ 
phone answering bureau which handles queries 
and requests for customer literature on a range of 
BT products and services including Callstream. 
All customer enquiries are potential sales and are 
therefore passed to the appropriate sales team to 
progress. 


Consumers of Callstream services are offered 
protection in the form of a code of practice pro¬ 
duced, managed and administered by ICSTIS. 
The code of practice provides the regulatory 
framework against which all premium-rate ser- 


t BT Products and Services Management 


Specialist Sales 

Dedicated sales account management teams pro¬ 
vide help and advice to potential and existing 
service providers. Account managers are the in¬ 
terface between BT and the service provider and 
offer guidance and support to customers on how 
best to support their service requirements. 
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Customer Service Centre 

Customer service centres provide technical and 
operational support for account managers and 
customers. The service-centre staff handle and 
process all orders for managed service and are the 
customer contact point for all queries and com¬ 
plaints on any issues. 

Derived Services Network Off-line 
Computerised Support System 

The off-line support system was developed to 
support derived services network (DSN)-based 
products such as Callstream and LinkLine and 
consists of two main parts, the order processing 
system and the charge raising system. 

Order Processing System 

The order processing system facilitates the entry 
of customer order details and distributes this 
information to network provisioning groups to 
allow for installation of Callstream and LinkLine 
services to be performed. The order processing 
system also provides the charge raising system 
with the necessary customer data for call record 
validation and charging. 

Charge Raising System 

The charge raising system calculates the char¬ 
ges for all calls made to services utilising the 
DSN. The number dialled and the duration of 
the call is logged at the appropriate DSN ex¬ 
change. At the end of each day, this information 
is fed into the charge raising system, which 
calculates the associated call charges and, for 
Callstream services, apportions the service pro¬ 
vider’s share of the revenue. The charge raising 
system relies on the order information on the 
order processing system to allocate the pay¬ 
ments and/or charges to the appropriate service 
provider. 

PROCESSES AND PROCEDURES 

The remaining part of this article describes the 
activities and processes associated with the pro¬ 
vision of services utilising the MRIS platform 
and covers the following areas (Figure 1): 

• pre-sales activity, 

® the sale, 

Q order processing, 

• revenue sharing and billing process, 

® fault reporting, and 

• after-sales support. 

Pre-Sales Activity 

Companies or individuals interested in finding 
out more about information services are encour¬ 
aged to contact BT Connections in Business for 
further details. Interest might have been stimu¬ 
lated by press advertising or recommendation 
from existing service providers. BT Connec¬ 
tions in Business takes initial enquiries, and 


dispatches brochures and the ICSTIS Code of 
Practice to callers. The caller’s details are then 
passed to the specialist sales group for lead 
qualification. 

The Sale 

All leads received by the specialist sales groups 
are qualified; that is, each caller is contacted 
within two weeks of the initial enquiry. The sales 
account managers fully discuss the customer’s 
needs and recommend the most appropriate ser¬ 
vice to satisfy these needs. The customer’s ser¬ 
vice requirements are fully researched, taking 
into consideration his/her short-, medium- and 
long-term requirements. 

New customers must complete and sign an 
application for service and return this to BT. If 
the customer is a limited company, a copy of the 
company registration certificate should be in¬ 
cluded. In line with standard BT policy, all new 
customer’s credit records are vetted before ser¬ 
vice is provided. 

Once the application form and any other 
documentation is received, the account man¬ 
ager arranges for a contract for service to be 
drawn up and signed by the customer. The con¬ 
tract details the customer’s exact service re¬ 
quirements; the associated connection charges 
and quarterly rentals, if appropriate; the esti¬ 
mated date for service to begin; and the tele¬ 
phone number(s) which have been allocated to 
the customer. 

On receipt of the signed contract, the order is 
then submitted to the service centre for process- Figure 1 
ing. Providing service 


SERVICE PROVIDER 
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Order Processing 

Order processing for both Callstream Managed 
and LinkLine MultiLink services is identical and 
performed by the appropriate product service 
centre. 

Order Entry 

On receipt of the order, the service-centre oper¬ 
ator inputs the customer’s order details from the 
contract onto the order processing system. After 
the initial entry, the order goes through various 
stages: 

The first stage is the proposed order stage , 
where details of the order are passed to the net¬ 
work provisioning groups for time-scales and 
tasks to be allocated . 

When the service-centre operator is satisfied 
that the details of the order are correct and the 
time-scales meet the customer’s requirements, 
the order is authorised and the network provision¬ 
ing commences 1 . 

When all the network provisioning is com¬ 
pleted, the service is ready for calls to be re¬ 
ceived. However, before calls to a service 
provider’s service can be charged at the correct 
tariff, each order has to be made ready for charg¬ 
ing. A simple code and a date are appended to the 
order and the service is then fully implemented. 
The charge raising system is then primed to log 
the call data it receives against the appropriate 
service provider’s number and calculates the 
revenue earned by each call. 

Once the order has been implemented, the 
service-centre operator arranges for a welcome 
pack to be sent to the service provider. The wel¬ 
come pack includes useful contact numbers and, 
if the customer is using remote update or any of 
the Enhanced Callstream features, all necessary 
access numbers, codes and personal identifica¬ 
tion numbers. 

Time-scales 

The standard time-scale for provision of Call- 
stream Managed service and LinkLine MultiLink 
service is 10 working days from receipt of the 
customer’s order. Time-scales for each order are 
negotiated between the service provider and the 
service-provision teams. If it is essential that the 
service be provided sooner, the service-provision 
teams endeavour to do so in order to meet the 
service provider’s needs. Callstream Enhanced 
Managed service customers are normally provided 
with service within five to eight working days. 

For Callstream Enhanced Managed service 
customers requiring to provide a live service 
using a direct connection, a timescale of 20 work¬ 
ing days is quoted. 

The Callstream customer service centre arran¬ 
ges for the customer to sign an additional contract 
for service for a private Speechline circuit. The 
service centre coordinates the provision and in¬ 
stallation of the complete order on the customer’s 
behalf. 


Revenue Sharing and Billing 

Callstream 

Revenue Sharing Process As outlined in an 
earlier article 1 , revenue earned from calls to Call- 
stream services is shared between the service 
provider and BT. The charge raising system logs 
the number dialled and the duration of the call in 
called seconds. The service provider receives an 
agreed amount per second and BT retains the rest 
of the revenue as a charge for the use of the BT 
network and facilities. 

Service providers are paid their share of the 
revenue, from which line or service rental is 
deducted, on a monthly basis. BT includes with 
the revenue cheque a tax invoice, pre-printed 
with a VAT amount, based on the revenue 
amount, which, if VAT registered, the service 
provider should present to HM Customs and Ex¬ 
cise Department. 

In order to keep administration costs for both 
service providers and BT to a minimum, revenue 
cheques are only processed for revenue earned of 
£500 or more. Monies accrue until this limit is 
reached and the cheque is then issued and dis¬ 
patched. 

Billing BT Callstream operates a self-billing 
process ; that is, any rental due is deducted at 
source from the service provider’s share of call 
revenue. Every month the service provider re¬ 
ceives, from the BT billing centre, a statement of 
accounts detailing the Callstream rental charges. 
Around the same time, the customer will receive 
a cheque for his/her share of the revenue from BT 
with the rental already deducted. 

LinkLine MultiLink 

LinkLine MultiLink is used mainly for campaign 
style promotions. BT offers full call-manage¬ 
ment facilities with this service and service pro¬ 
viders rent LinkLine telephone numbers instead 
of lines. Charges for both the number(s) and the 
call charges are associated with the service pro¬ 
vider’s PSTN telephone number and detailed on 
the normal quarterly PSTN invoice. 

Fault Reporting 

Callstream Managed Service and LinkLine 
Service 

BT’s managed service equipment is self monitor¬ 
ing and if any faults occur, they are normally 
identified and repaired before the service pro¬ 
vider is aware that they have occurred. 

If, however, the service provider does dis¬ 
cover a service fault, he/she is encouraged to call 
the 24-hour fault reporting point (FRP) on 0800 
110011. All fault reports are logged and pro¬ 
gressed by the digital derived services network 
FRP. The FRP staff refer to the customer’s service 
records, which are stored on a maintenance data¬ 
base; these records identify the managed services 
equipment on which the service provider’s ser- 


British Telecommunications Engineering, Vol. 11, April 1992 


55 



vices are operated. The appropriate an¬ 
nouncement-centre staff are contacted and the 
fault details are passed over for clearance. The 
FRP remains in control of the fault and advises 
the service provider of progress and when the 
fault is cleared. 

If a fault is received outside normal working 
hours, currently only a fault reception service is 
available. 

CallStream Enhanced Managed Service 

As with the other managed services, all equip¬ 
ment on the CallStream Enhanced Managed ser¬ 
vice is fully self monitoring. If any faults occur 
on the service, service providers are encouraged 
to call 0800 155255; this number is answered at 
the network management centre at Oswestry, 
which provides 24 hour, year-round fault recep¬ 
tion. On receipt of a fault report within normal 
working hours, the details are passed to the na¬ 
tional announcement centre (NAC) for clear¬ 
ance. The service provider is kept informed on a 
four-hourly basis of progress and advised as soon 
as the fault is cleared. 

When faults are received outside normal 
working hours, the network management centre 
staff either pass the fault to the NAC the next 
working day or call out a member of the NAC 
team, depending on the seriousness of the fault 
report. 

After-Sales Support 

There are two types of after-sales support 

® account management, and 
© customer after-sales service. 

Account Management 

Service providers are contacted on a regular basis 
by the specialist sales team. The account-man¬ 
agement function ensures that the service pro¬ 
viders are kept informed of the latest product 
developments and offers a forum for both BT and 
the service provider to identify potential growth 
opportunities. 

Customer After-Sales Service 

The customer service centre offers an essential 
after-sales support function to all service pro¬ 


viders and deals directly with any requests for 
modifications to existing services. The service 
centre provides technical guidance on all service 
matters and is the customer contact point for any 
queries or complaints regarding billing, revenue 
and statistical issues. 

CONCLUSION 

With the advent of new, and increasingly sophis¬ 
ticated, network features designed for use within 
the information-service environment, product 
support functions perform an important pivotal 
role in ensuring service provider’s needs are dealt 
with in a quality manner, matching up their needs 
with the very best products and services BT has 
to offer. By investing in the best technology and 
by placing emphasis on the development of solid 
processes, BT is consolidating its position as the 
service provider’s first choice of network pro¬ 
vider. 
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Managed Recorded Information Services—Network 

Operations 

IAN HOLMESt 


Operation of the managed recorded information sendees (MRIS) platform is described , along with the 
provision and management of the sendees. Access to the MRIS platform is via the derived services 
network and, potentially, the public switched network. Maintenance of the network and equipment is 
covered. 


INTRODUCTION 

Managed recorded information services (MRIS) 
have grown with developments in the derived 
services network (DSN). The MRIS operations 
comprises service provision, control and main¬ 
tenance of the MRIS platform, which itself com¬ 
prises eight regional recorded announcement 
centres (RACs) and the national announcement 
centre (NAC). Owing to their close associations 
with DSN developments, each RAC is collocated 
with a DSN node. A standard basic configuration 
has been adopted for all RACs with interconnec¬ 
tion to the NAC, which is based at Oswestry. 
Figure 1 shows a schematic diagram of the access 


network and an RAC. More information can be 
found in the overview article describing the his¬ 
tory and architecture of MRIS 1 . 

A 2 Mbit/s communications network intercon¬ 
nects and provides the capability to transfer in¬ 
formation between the RACs and the NAC (see 
Figure 2). Reference 1 details how the RACs are 
configured within the network. 

There are two levels of services provided on 
the MRIS platform: 

© those which use the auxiliary switch in com¬ 
bination with voice services equipment (VSE); 
and 

O those which use the RIDE network. 


Figure 1 - 

Access network t BT Worldwide Networks 



DDI: Direct dialling in 
DDSSC: Digital derived services 
switching centre 
DLE: Digital local exchange 
DMSU: Digital main switching unit 
DSN: Derived services network 


NAC: National announcement centre 
RAC: Recorded announcement centre 
RIDE: Recorded information distribution 
equipment 

VSE: Voice services equipment 


The auxiliary switch and VSEs are designed 
to handle a high number of different service 
announcements, but with a relatively low call 
volume, whereas the RIDE network handles high 
call volumes, but with fewer services available. 
The RIDE itself offers two services—televote 
and broadcast. 

Further information on these systems can be 
found elsewhere in this issue of the Journal 3 ’ 4 . 

OPERATIONS 

The MRIS platform consists of specialised and 
unique sets of network equipment which, be¬ 
cause of the relatively small number of people 
involved, allow for economies of scale by cen¬ 
tralising many of the functions and expertise at 
the central operations unit (COU). This is a 
small dedicated team of experts who have re¬ 
sponsibilities spanning across the whole plat¬ 
form. 

The central MRIS operations team has the re¬ 
sponsibility for operational processes and proce¬ 
dures for the MRIS platform. It is responsible for 
the introduction of new services (for example, 
Callstream and LinkLine services) and negotiates 
the interfaces in the customer-facing groups (BT 
Business Communications). In addition, the team 
decides on the most appropriate way for an order 
to be processed and progressed through the system, 
and is also responsible for capacity management 
and equipment utilisation within the MRIS plat¬ 
form. 
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Service Provision 


The provision of service can best be described by 
following the flow of a customer’s order once it 
has been taken by the sales force 2 . 

Depending on the volume of calls anticipated, 
the customer will either purchase a VSE service 
(low call volumes, but a high number of services) 
or a RIDE service (high call volumes, but a low 
number of services). Other options which have to 
be considered if the service is to be provided on 
the RIDE network are whether to have televote 
or broadcast, start-at-the-beginning, or non-start- 
at-the-beginning announcements, remote update, 
live feed and so on. These decisions are taken 
following discussions and negotiations with the 
sales force. 

A help desk is in operation at the COU at 
Whittington House, Oswestry, which provides 
help to the sales force during the initial negotia¬ 
tions. For example, sales staff may wish to check 
on the availability of equipment, or ascertain 
certain information such as possible time-scales. 

After this interactive process, and once the 
most suitable services have been decided upon, 
the sales force submit the order to the Callstream 
customer service centre, which performs valida¬ 
tion checks. 

If the lead time is less than standard, the sales 
force will need to contact the service provision 
team and check that the service can be delivered. 

Order Processing 

If time-scales and validation checks prove satis¬ 
factory, then the customer service centre builds 
the order on the order-processing system. This is 
part of the DSN off-line support system and is 
based at the computer centre in Bletchley. It is a 
task-based system which directs requests for in¬ 
formation to specific workqueues. For all MRIS 
orders, a task will appear on a workqueue at the 
MRIS service provision team at Oswestry. 

As shown in Figure 3, the customer’s require¬ 
ments together with the required-by date are built 
into the order processing system screen, and this 
is forwarded within the system to appear on a 
single workqueue at the COU at Oswestry for 
assessment of the MRIS order. The order-pro¬ 
cessing system screen carries all the details about 
the customer, but it does not define where the 
service is to be provided; this is decided by the 
service provision team. 

Equipment Ailocation 

When the order arrives at the COU, the customer’s 
requirements are analysed and a decision is made 
as to which of the eight RACs is best suited for the 
service—RIDE services are only provided at the 
NAC. If it is to be placed in a RAC, a number of 
factors are taken into consideration in order to 
maximise the utilisation of equipment and spread 
workloads. For example, if the order is from an 
existing customer, then attempts are made to place 
these additional services at whichever RAC is 


TO RAC LAN 



TO RAC LAN T0 


o pmux eh «* 


LAN: Local area network PMUX: Primary multiplexer 

NAC: National announcement centre RAC: Recorded announcement centre 


already holding the customer’s present services. 
However, there are times when this is not always 
possible or even desirable. Certain other factors 
have to be considered; for example, the service 
capacity of each RAC, whether the customer’s 
requirements include tape update or remote up¬ 
date, and so on. 


Figure 2 

Communications 
network for DSN 


Figure 3 

Order processing 
system screen 
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ORDER/D CUSTOMER ORDER DETAILS DDM31900 

CustoMer Nane: PSTN CNA ANNOUNCEMENTS Reference : 040454 

Order Reference : 070385 Corihents Attached Consultant : MARIOI 

Key Dates For This Order Order Status Date 

Ordered : 03/02/92 BT Target : 04/02/92 Preu: 070214 IMPLEMENTD 07/02/92 

Required : 03/02/92 Seruice Date: 03/02/92 This: 070385 IMPLEMENTD 07/02/92 

Authorised : 03/02/92 Responsible : MARIOI Next: 070391 AUTHORISED 03/02/92 

ProductLine: TNS Order Office: RSMORDER 

Action IteM Description ProductiteM Status 

PROUIDE Published nuMber 0800 XXXXXX Ansuered at X/0800 Inplenentd 
BS/RAC (R03) fron catchMent area ALL Packaging 0800 L3 


Short Tern Seruice Cease-On Date: Order Supercedes Order : 

CoMhand: 

DC900043 All data displayed 

V_ J 
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The COU receives reports from the RAC man¬ 
agers during the last full week in each month 
giving the available capacity at each site. This 
enables the COU to fulfil its capacity manage¬ 
ment function. 

If the customer requires tape update of his 
service, then this demands more work of the RAC 
staff as, unlike remote update, the staff have to 
physically load tapes. It is the function, therefore, 
of the COU, to balance the workload of the 
RACs, ensuring none are overloaded and, 
equally, none are under-utilised. 

Once it has been decided which RAC should 
support the service, the MRIS service provision 
team shows, via the order-processing system, the 
proposed order to that RAC. This provides details 
of the service requirement; that is, BT target date 
for provision, message length, service type 
(remote update/tape/live feed). This is usually 
followed up by a telephone call. Once the RAC 
staff confirm they can support the order, it is 
accepted by MRIS service provision. Acceptance 
is transmitted back to the customer service centre 
via the order processing system and the customer 
is advised. The order-processing system automat¬ 
ically generates the appropriate tasks on the 
workqueue at the chosen RAC. 

If, for whatever reason, the order’s target date 
cannot be met, the order is rejected and the reason 
explained to the customer, usually with a revised 
date being offered. 

The RAC staff then allocate the appropriate 
capacity and file areas on a VSE as well as service 
code(s)—two-digit direct dialling in (DDI)—to 
access the service(s). They establish a routing 
across the auxiliary switch to the appropriate 
VSE: this involves preparing auxiliary switch 
routing translations. The preparation work could 
include setting up remote update details on the 
VSE as well as the translation on the auxiliary 
switch. Further details of the translation tables 
can be found in the article covering the auxiliary 
switch and VSEs 3 . The network address, which 
comprises the auxiliary switch routing number, 
the auxiliary switch routing and VSE service 
code, is entered onto the order processing system 
and filed. This operation causes the order pro¬ 
cessing system to generate an order on a work- 
queue within the DSN data operations team. This 
COU team prepares and loads the translation data 
linking the dialled telephone number and net¬ 
work address on all the DSN switching centres. 

Update Service 

If the customer requires remote update of their 
announcements, the RAC staff provide details of 
the 0800 number used to access the particular 
VSE. In addition, they also assign the service 
code and personal identification number (PIN) 
on the VSE to provide secure customer access to 
update their announcements. All these details are 
conveyed, via the order-processing system, to the 
customer service centre, which provides the rele¬ 
vant instructions to the customer. 


For a tape updated service, the customer is 
advised to send a normal audio cassette tape of the 
announcement to the BT Tape Centre in Bristol, 
where it is vetted and then forwarded to the rele¬ 
vant RAC. The MRIS service provision team ad¬ 
vises the distribution centre of all new provisions, 
changes or cessations. The tape must be received 
in Bristol at least two days before the message is 
due to go on the network. Announcement centres 
will not accept tapes directly from service pro¬ 
viders. The vetting is for quality of content only 
and the centre is working to ICSTIS (Independent 
Committee for the Supervision of Standards of 
Telephone Information Services) guidelines. The 
day before the service is due to start, the tape is 
loaded onto the correct VSE. 

RIDE Services 

A similar provisioning process is followed for the 
RIDE services: the order comes to the MRIS 
service provision team as a RIDE order and, as 
long as the due date can be met, the service is 
accepted for the DSN RIDE platform. 

In the case of the RIDE, instead of the task 
appearing on RAC workqueues, the order ap¬ 
pears at the NAC’s workqueue, where the staff 
check service availability, whether the service is 
start-at-the-beginning, whether a pre¬ 
announcement is required, whether it is a live 
feed etc; and allocate the appropriate number of 
channels. As before, the PIN number and service 
codes are supplied to the customer, via the cus¬ 
tomer service centre, if remote update service is 
required, together with online statistics service 
PIN numbers and service codes. 

There are fixed translation tables within the 
RIDE which use three-digit DDI to determine the 
service characteristics (for example, message 
length and caller timeout) and channels on which 
the service is provided; for instance, a single 
service would have a pre-announcement on a 
different channel than its main announcement. 
The NAC staff determine the three-digit DDI 
code(s) required to provide the desired an¬ 
nouncement characteristics and enter the details 
on the order-processing system to instigate pro¬ 
vision of DSN translation data. 

Basic Services 

On the RIDE, the customer can purchase one of 
two services: 

@ televote, or 
• broadcast. 

Televote services are those which enable votes 
to be cast simply by ringing one number repre¬ 
senting a caller’s choice from a range of possible 
options available. They tend to have short hold¬ 
ing times, typically 5 s. The message that is heard 
thanks the caller for voting and announces that 
the caller’s vote has been registered. This service 
is useful for events which demand that the public 
vote on particular items, such as the various acts 
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on ‘Opportunity Knocks’ or the UK entries to the 
Eurovision Song Contest. 

For televotes, further announcements to the 
service can be networked, depending on the time 
called, advising callers that: 


monitor alarm unit to monitor until the customer 
updates the service either by supplying a tape or 
by remote update. 

Live-Feed Service 


% the service has not yet commenced, or 
# that the service has closed. 

Broadcast services are continuous information 
services, normally of longer holding times, such as 
those used by bookmakers to give live commen¬ 
taries of sporting events, or results services. 

For the RIDE orders, the NAC staff prepare 
the VSEs at the head of the RIDE rings on which 
the announcements are to be loaded, and the 
relevant PIN numbers and service codes are 
determined. In addition, the online statistics sys¬ 
tem needs to be programmed to collect and col¬ 
late statistics for the service and channels that are 
being used to support the service. The customer 
is provided with the relevant information to en¬ 
able him/her to obtain statistics for the service. 

The monitor alarm unit is also set up to moni¬ 
tor the new service, and a test message is loaded 
on the particular channels to be used. This mess¬ 
age provides a continuous announcement for the 


For live-feed customer services, private wires are 
installed from the customer’s premises to the near¬ 
est RAC. For security, two private wires are sup¬ 
plied, acting as a main and stand-by. Each are 
allocated two channels on the communications 
network (see Figure 4), one with direct connection 
to the NAC, the other via an alternative RAC for 
increased security. The NAC staff then perform an 
end-to-end test from the customer’s premises right 
through to the NAC to ensure the correct audio 
levels are received. The service is then patched into 
the appropriate channel on the RIDE network. 

All live feeds and remote-update messages are 
recorded and retained for 28 days to comply with 
OFTEL (Office of Telecommunications) regula¬ 
tions. Thus, any networked message can be re¬ 
trieved and replayed in the event of a complaint. 

RACAL voice-activated recorders are installed 

in each RAC and the NAC to monitor these direct 

feeds and updates. Equally, tape-updated mess- Figure 4 

ages are retained for the same period. Live feed access 
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Service Management 

Service management can be considered as the 
matching of available resources to the traffic 
volumes. 

An RAC manager monitors the utilisation of the 
particular services at the RAC. If a particular VSE 
service is detected generating high call volumes, 
causing congestion, then a number of options are 
available. For example, the number of lines to that 
service can be increased in order to provide addi¬ 
tional answering capability, which could result in 
the service being provided over two VSEs. 

A further option available to RAC staff is to 
utilise the auxiliary switch wait-on-start facility. 
This facility enables the auxiliary switch to be used 
as a concentrator. The auxiliary switch can be 
programmed to wait until a pre-set number of 
incoming calls has been received, and can then 
switch all of these calls through together to one 
VSE line. The parameters that can be varied are 
elapsed time and number of calls. Thus, the auxil¬ 
iary switch waits until, say, five calls have been 
received, or a set time has elapsed, say 5 s, which¬ 
ever occurs first. A balance must be achieved with 
the parameters being set to ensure call connection 
is not delayed significantly. This facility provides 
a greater utilisation of VSE lines. 

It is possible that the RAC manager may de¬ 
cide, in conjunction with the MRIS service-pro¬ 
vision team, that the service is stimulating too 
many call attempts and would be better suited to 
operate on the RIDE systems. The MRIS service- 
provision team generates the necessary orders on 
the order-processing system, involving the NAC 
staff. The service can then be transferred from the 
VSE to the RIDE network. The calling customers 
will notice no difference, but the service provider 
is kept informed at all times and provided with 
new telephone numbers for on-line statistics and 
remote update access. 

One of the aims of MRIS operations is to restore 
services upon failures as quickly as possible. The 
use of security channels on the RIDE reduces the 
risks to these services, while for services held at 
the RACs there is the ability to use the auxiliary 
switch to by-pass failed equipment and restore 
service on other equipment without the customer 
being aware of the failure. 

Quality of Service 

Several quality-of-service resources are placed 
on MRIS operations. These quality-of-service 
targets basically cover three areas: 

$ the standard lead times for provisioning; 

• termination capacity (to terminate success¬ 
fully 98% of all MRIS calls that arrive at the DSN 
node in a 48 hour period); and 

• fault repair (targeted to restore to service any 
failure by the end of the next working day). 

The fault repair target is the contractual agree¬ 
ment, but the reality is that networks achieve a 
4 hour restoration in the vast majority of cases. 


BT’s Online Statistics Service 

Call statistics are provided by the opinion poll 
registration application (OPRA) system. 

The OPRA collects data on the usage of re¬ 
corded information services and makes this data 
available to the service providers. 

NAC staff program the OPRA system to pro¬ 
vide statistics matching the particular service; for 
example, single or multiple outputs. 

Statistics 

There are two methods for customers to obtain 
the online statistics. They can dial the OPRA 
equipment from a suitable personal computer 
(PC) associated with a modem. They then are 
prompted for a service code number and PIN 
number of the particular service for which they 
wish to obtain statistics. The OPRA prompts the 
caller to clear down and dials the customer’s 
terminal back a short time later and downloads to 
the PC the data requested. 

Alternatively, the customer can dial the OPRA 
equipment with a TouchTone™ telephone, again 
entering a service code/PIN combination. On 
selecting the information required, the OPRA 
provides the latest statistics directly over the line 
by using voice messages (only call totals per 
service are available with this method). 

Customer Services 

Three basic types of service are available to cus¬ 
tomers: 

• Detailed statistics service this provides de¬ 
tailed statistics on the number of calls and their 
accumulated call holding times split over eight 
regions for each 15 minute period. 

• Summary statistics this provides the aggre¬ 
gate total of calls to a set of numbers, split over 
eight regions. 

O One minute statistics this is similar to the 
summary statistics, but provides data on a one 
minute time period. 

Normal circumstances are such that custo¬ 
mers access the OPRA system directly either by 
dual-tone multi-frequency (DTMF) signalling or 
by PC and modem; however, there are adminis¬ 
tration screens which allow the NAC staff to 
retrieve data and archive data. These administra¬ 
tion screens take the following format. 

0, Summary of today’s data for all regions 

1, Today’s data for regions 0 and 1 

2, Today’s data for regions 2 and 3 

3, Today’s data for regions 4 and 5 

4, Today’s data for regions 6 and 7 

5, Today’s data for all regions 

6, Daily totals for all regions for the last 
7 days 

7, All region report for today -1 

8, All region report for today -2 and 
today -3 

9, All region report for today -4, today -5 
and today -6 

where region refers to DSN regions. 
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Accumulated call holding time is also given 
in a similar format. Figure 5 shows a typical 
report. 

With a summary report, the call-count totals 
for each region are presented automatically; 
there are no other options. Figure 6 shows a 
typical report. 

The OPRA database retains call data for seven 
days, but to enable reports to be available for 
earlier periods, archiving is provided, with 
archives being retained for 28 days. 

Among the benefits to customers is the ability 
to determine the impact and effectiveness of ad¬ 
vertising campaigns on a regional basis. For 
example, by looking at the results over a 24 hour 
period a customer can determine which televi¬ 
sion advertisements produced the best response. 

MAINTENANCE 

Within Worldwide Networks, the Operational 
Policy and Systems unit has responsibility for 
defining the processes and the procedures relat¬ 
ing to the maintenance of MRIS equipment. Con¬ 
sequently, for each element within the MRIS 
platform, which could originate from a variety of 
manufacturers, this team determines the support 
requirements. These requirements include the 
level of first-line maintenance required, what 
spares should be carried within BT, where they 
should be held, etc. 

This team negotiates and establishes with 
manufacturers or other support agents a mainten¬ 
ance support contract. The contract defines the 
level of support required from the company; that 
is, whether it is a 24-hour-call-out, or a next- 
working-day service etc. The support contracts 
are negotiated to provide appropriate cover to 
meet the quality-of-service targets and provide 
for automatic software upgrades. 

Once these maintenance contracts have been 
negotiated and agreed they are effectively 
handed over to the maintenance groups who can 
call upon the contracts when necessary. 

The responsibility of maintaining the RIDE 
system is that of the NAC staff using the recorded 
information service control processor (RISCP) 4 , 
while maintenance of the auxiliary switches and 
VSEs is the responsibility of the RAC staff. Con¬ 
sequently, any alarms on the RIDE switches, 
although physically located at the RACs, are fed 
to the RISCP at the NAC. There are no RIDE 
alarms, other than power alarms, in the RAC. 

The MRIS support manager monitors the sup¬ 
port contract to ensure that it has been fulfilled 
and negotiates renewals. 

Responsibilities 

The RAC manager is responsible for the main¬ 
tenance and availability of all the equipment in 
the RAC, with the exception of the RIDE switch. 
This includes the monitoring of all the printouts 
and alarms for indications of any problems, and 
the rectification of such problems by following 


DETAILED REPORT 
Report Time 

Customer Name 
Customer Address 

Contact Name 
Contact Telephone 
FAX Number 
Dial-back Number 

Service Name 

Service Start Time 

Service Stop Time 


14:20 

Thu Jan 23 1992 

NAC 

WHITTINGTON HOUSE 
OSWESTRY 


LONDON CODE CHANGE 
00:00 

Tue Dec 10 1991 

00:00 

Fri Dec 10 1999 


FOR MANAGEMENT PURPOSES ONLY 
CALL COUNTS 

Summary For All Regions 
Data for : Thu Jan 23 


Time 

:00/:15 

: 15/ : 30 

: 30/:45 

:45/:00 

TOTAL 

0:00 

88 

88 

68 

89 

333 

1:00 

48 

56 

40 

30 

174 

2:00 

24 

32 

27 

22 

105 

3:00 

17 

30 

14 

15 

76 

4:00 

15 

25 

21 

34 

95 

5:00 

46 

15 

23 

38 

122 

6:00 

32 

32 

70 

75 

209 

7:00 

67 

86 

154 

196 

503 

8:00 

307 

460 

556 

797 

2120 

9:00 

1434 

1945 

2229 

2407 

8015 

10:00 

2555 

2612 

2596 

2620 

10383 

11:00 

2660 

2649 

2660 

2550 

10519 

12:00 

2421 

2325 

2200 

1908 

8854 

13:00 

1897 

1741 

1819 

1999 

7456 

14:00 

15:00 

16:00 

2587 




2587 

0 

o 

17:00 

18:00 

19:00 

20:00 

21:00 





0 

0 

0 

0 

o 

22:00 





o 

23:00 

Daily Total 





0 

51551 


'.' > Not Available 


the correct maintenance procedures. The man- Figure 5 
ager is supported by technical officers and, in Typical detailed 
some sites, clerical staff, who may have addi- statistics report 
tional responsibilities. 

A technical support function is available at the 
COU to the RAC and NAC managers for VSE 
applications such as remote update, remote up¬ 
date with live feed, and basic managed interac¬ 
tive services. Any new software releases of either 
VSE operating systems or applications supplied 
by BT’s Development and Procurement are first 
loaded onto the equipment at the COU test bed 
and tested to ensure they are functioning correct¬ 
ly and fit for operational use. Only then are they 
rolled-out to the RACs. 

If there is a hardware problem at an RAC, the 
RAC manager escalates directly to the manufac¬ 
turers; software problems, however, are esca¬ 
lated to the support unit at the COU. For example, 
if there are problems on a VSE in an RAC and 
the RAC manager suspects it is a software prob¬ 
lem, then COU staff have the facility to interro¬ 
gate the VSE system remotely. They can ‘walk’ 
through the system, the pointers, the files and so 
on, and ascertain if it is a software problem, 
effecting some software repairs remotely from 
the NAC. 

The support team have similar responsibility 
for the auxiliary-switch software. An auxiliary 
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RIDE Maintenance 


SUMMARY REPORT 





Report Time 

: 19:20 





: Thu Jan 23 

1992 



Customer Name 

: BT 




Customer Address 

: NAC 





WHITTINGTON 

HOUSE 



Contact Name 

: NAC 




Contact Telephone 





FAX Number 





Dial-back Number 





Report Name 

: NATIONAL TELEVOTE 

DEI-IO 


Report Start Time 

: 00:00 





: Tue Oct 8 

1991 



Report Stop Time 

: 00:00 





: Fri Oct 8 

1999 



Last Reset 

: 18:00 





: Thu Jan 23 

1992 



Last Collected 

: 18:50 





Thu Jan 23 

1992 




FOR MANAGEMENT 

PURPOSES ONLY 





REGION 

TOTAL CALLS 

1 CHOICE 1 






0891xxxxxx 


1 

2443 


0891xxxxxx 


2 

2401 


0891xxxxxx 


3 

3422 


0891xxxxxx 


4 

2602 


0891xxxxxx 


5 

2353 


0891xxxxxx 


6 

1971 


0891xxxxxx 


7 

3391 


0891xxxxxx 


8 

2252 





20835 

2 CHOICE 2 






0891xxxxxx 


1 

4113 


0891xxxxxx 


2 

5452 


0891xxxxxx 


3 

6502 


0891xxxxxx 


4 

4363 


0891xxxxxx 


5 

4571 


0891xxxxxx 


6 

3781 


0891xxxxxx 


7 

5372 


0891xxxxxx 


8 

4332 





38486 


Figure 6 

Topical summary 
statistics report 


Figure 7 
RISCP screen 


switch is held at the COU, where the staff repli¬ 
cate problems encountered at an RAC in an at¬ 
tempt to understand and resolve them. 

In summary, the support team has two func¬ 
tions, the pre-release testing of new software and 
assisting in the resolution of any problems or 
operational difficulties in the VSEs and auxiliary 
switches. 
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The RISCP provides central management of the 
RIDE system. It monitors each of the DSN RIDE 
switches and receives alarms. From this PC, the 
RIDE switches can be fully controlled, con¬ 
figured and maintained, with the ability to inter¬ 
rogate system status, etc. 

The RISCP shows a continuous on-screen dis¬ 
play of the current alarm status of all the RIDES 
connected to the RISCP. This is shown in the 
form of a banner across the top of the screen, as 
shown in Figure 7. The alarms are colour coordi¬ 
nated depending on their severity. In addition to 
the alarm information in this banner, there is also 
an audible tone output. 

Consequently, the people at the RACs do not 
need in-depth knowledge of the RIDE switches; 
NAC staff use the RISCP to interrogate the swit¬ 
ches and locate, for example, faulty equipment 
which requires changing. 

Alarms 

Heat and environmental alarms are local RAC 
alarms while, on the RIDE network, all other 
alarms are reflected back onto the RISCP, enab¬ 
ling all fault management and investigation of the 
RIDEs to be carried out at the NAC. 

Within the NAC, technical officers are respon¬ 
sible for monitoring and maintaining all the equip¬ 
ment within the NAC, and for monitoring the 
RIDE switches. They will use the RISCP as a 
means to identify a fault in a RIDE switch, and they 
effect a repair by instructing the RAC staff which 
cards to change. Once a switch has been repaired, 
the RAC manager is responsible for sending any 
faulty cards to the manufacturer for repair. 

If any faults occur on the 2 Mbit/s RIDE ring, 
for example a channel is lost, then the monitor 
alarm unit activates an alarm and NAC staff use 
the RISCP to investigate the system. They can 
isolate the fault by investigating which RIDE is 
not receiving the correct 2 Mbit/s conditions. De¬ 
pending on the alarms in the REDE switches, staff 
can determine whether it is the 2 Mbit/s system 
which is faulty or a splitter 4 . It is then possible to 
isolate the fault to a particular 2 Mbit/s section. 

If it is a 2 Mbit/s system failure, the network 
management centre is contacted to ascertain if a 
major transmission failure has occurred and to 
determine a predicted time to repair the service. 
Because of the security and replication aspects of 
the RIDE equipment and rings there has never 
been a total loss of service. 

If it is a 2 Mbit/s splitter card problem, the 
NAC will contact the local repeater station and 
request a change of the splitter board. NAC staff 
are then able to confirm correct functioning of the 
system once the replacement is effected. 

Contingency plans exist in case a RIDE switch 
fails completely. In these circumstances, calls for 
a particular RIDE switch can be diverted across 
the DSN network to be terminated on another 
RIDE switch. 
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Two classes of alarms are identified at the 
NAC: 

<& prompt and 
© deferred. 

Prompt alarms denote problems that are 
potentially service affecting; examples are: 

© power loss, 

© RISCP polls a RIDE switch and receives no 
response, or 

© failure on the supervisory processor within a 
RIDE switch. 

Deferred alarms are less serious, non-service- 
affecting alarms. A deferred alarm is one that has 
occurred but does not sufficiently deteriorate the 
service offered to the customer to warrant imme¬ 
diate action. 

A prompt alarm is investigated immediately, 
whereas no deferred alarm is left for more than 
two hours before investigations are initiated. 


agement centre staff to maximise the calls to the 
customer and still protect the network. If such 
discussions do not occur, then staff at the network 
traffic management centre will see unexpected 
congestion occurring and act to protect the net¬ 
work. This may inadvertently restrict the number 
of calls the customer is receiving. 

Pre-event plans are instigated with call gap¬ 
ping installed in preparation, as far back in the 
network as possible with the gap interval calcu¬ 
lated to ensure the customer’s lines are filled 
without jeopardising the network. 

In call gapping, the number of calls which 
can be offered to a particular number are re¬ 
stricted by setting time windows, the lowest 
being 0-1 s, which only allows one call through 
per window (see Figure 8). Consequently the 
higher the call volume expected, the wider the 
window. The rejected callers will hear the cus¬ 
tomer busy tone. 


NETWORK MANAGEMENT 

The function of network management is to maxi¬ 
mise call completions without jeopardising the 
network or the other customers of the network. 

Consequently, there is 24 hour monitoring of 
call traffic and control of this traffic where 
necessary. The traffic-management system re¬ 
ceives route and traffic statistics every five 
minutes, which are used to monitor directly traf¬ 
fic accessing all the RIDE routes. 

Identification of traffic congestion is provided 
when thresholds are exceeded. In order to pre¬ 
vent other customers losing their ability to com¬ 
plete calls, the network management centre can 
control traffic by restricting call attempts to par¬ 
ticular numbers that are generating high call vol¬ 
umes. 

An example of the volume of calls which can 
occur is that during the first 15 minutes of choos¬ 
ing the UK entry for the 1991 Eurovision Song 
Contest, 2-5 million calls were generated. Even 
though these calls were terminating on the RIDE, 
the network had difficulty handling this large 
volume of instantaneous calls. 

When customers are planning to operate an 
event likely to generate high call volumes, it is 
imperative that the network management centre 
is informed in advance with an estimate of call 
volumes and the number of terminating lines 
available. The network management centre can 
then plan to protect the network and other callers 
while ensuring the event maximises the call ter¬ 
minating capabilities. For example, if the event 
is expected to generate high call volumes, nego¬ 
tiations with the organisers are imperative to 
ensure the event does not conflict with anything 
of a similar size. 

Hence, it is to the benefit of the service pro¬ 
vider to inform the network management centre 
how many lines they have available, when the 
service is going to be run, and how many calls 
are expected. This will enable the network man¬ 
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Principles of call 
gapping 


Network Utilisation of MRIS Facilities 

Although the MRIS platform was installed speci¬ 
fically for Callstream services, other applications 
such as LinkLine and network announcements use 
its capabilities. A prime example is the use of the 
announcement services for network change-of- 
number announcements. The most recent major 
event was the London code change, for which 
announcements were provided initially at the 
DMSU RIDEs and later migrated to the DSN 
RIDE. The London code change announcements 
18 months after the change-over were still receiv¬ 
ing 700 000 calls per week. 

It is planned that the national code change 
announcements will be provided on the RIDE 
system. 

As a result of action taken to provide an¬ 
nouncements during the loss of service result¬ 
ing from a fire in the Scarborough exchange, a 
permanent service has been provided on the 
DSN RIDE to enable the network management 
centre to provide network announcements in 
the event of major service failures. Permanent 
decode data has been installed at each DMSU 
which allows the network management centre 
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to reroute any calls to a RIDE announcement. 
They can update the announcement by using the 
remote update facility to give specific informa¬ 
tion to the calling customers as to why their call 
cannot be completed. Initially provided as a 
UK-only facility, it is now also accessed by 
international services. 

Fault Reporting 

BT’s Callstream managed service and LinkLine 
service equipment is self monitoring, and if any 
faults occur, they are normally identified and 
repaired before the service provider is aware it 
has occurred. 

If, however, the service provider does dis¬ 
cover a service fault, a 24-hour fault reporting 
point is available. All fault reports are logged and 
progressed by the digital derived services net¬ 
work fault reporting point. The fault reporting 
point staff refer to the customer’s service records 
stored on a maintenance database to identify on 
which managed services equipment the services 
are operated. The appropriate announcement- 
centre staff are contacted and the fault details are 
passed over for clearance. The fault reporting 
centre remains in control of the fault and advises 
the service provider of progress and when the 
fault is cleared. 

If it is a network fault, it is handed over to the 
DSN centralised maintenance team in London. If 
it is a REDE service fault, it is passed to the COU 
for investigation. 

All NAC alarms are extended out of hours to 
the COU building alarm system which identifies 
to the 24 hour security personnel on the COU site 
which alarm has been activated; that is, whether 
it is a monitor alarm unit or RISCP alarm. The 
security staff have detailed instructions on their 
course of action. There are technical officers 
on-site 24 hours a day who have been trained to 
respond to alarms in the NAC. One of these 
officers is advised of the alarm and performs 
first-line analysis of the problem. If, however, 
this is insufficient to rectify the problem, the 
officer instigates a call-out to the NAC technical 
support. 

SUMMARY 

Operation of MRIS has been described here, 
together with details of the benefits to its custo¬ 
mers and to BT. 

Service provision has been detailed by follow¬ 
ing the flow of a customer’s order, and the deci¬ 


sion processes involved have been described. 
Service management has been considered with 
respect to monitoring traffic for congestion, and 
has included details of quality-of-service targets. 
Maintenance of the MRIS equipment and the 
roles and responsibilities of the various personnel 
have been detailed. 

Finally, network management, which is the 
maximisation of call completions, has been dis¬ 
cussed and has emphasised the importance of 
negotiations with the customer in order to pro¬ 
vide the best possible service. 
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Successes and Future of Managed Recorded (Information 
Services 

BILL JONESt and IAN HOLMES* 


In this article , the recent successes of managed recorded information services (MRIS) are reviewed 
and shows how the flexibility of MRIS has allowed BT to respond to customer's needs. An indication is 
given of the flavour of some of the possible figure MRIS products. 


INTRODUCTION 

The development of managed recorded informa¬ 
tion services (MRIS) from the first application, 
the speaking clock, to today’s comprehensive 
portfolio has not been achieved in a steady linear 
way. The past 50 years has seen an explosion of 
information services (see Figure 1). There have 
been four key milestones throughout this period: 

# introduction of the speaking clock service, 

© expansion of the speaking clock into the 
Guidelines service, 

© introduction of MRIS, and 
© launch of Callstream Enhanced Managed Service. 

Many factors have influenced the develop¬ 
ment of MRIS, notably the prevailing technical 
and commercial environments. For most of the 
past 50 years, relatively little advancement was 
made in recorded information services. 

The speaking clock was the earliest form of 
automation, introduced primarily to reduce the 
demand on the then British Post Office telephone 
operators. The driving force behind the introduc¬ 
tion of Guidelines was to stimulate telephone 
usage, especially outside the busy periods. 

It has only been since the privatisation of BT, 
and the availability of premium rate services, that 
real growth has taken place in the MRIS market 1 . 
This growth will continue, responding, as in the 
past, to the prevailing customer demand for in¬ 
creased features and service flexibility. It is use¬ 
ful to note that the customer (that is, the service 
provider) rents MRIS from BT, while it is the 
caller who uses the telephone network to access 
the information. 

SUCCESSES 

The success of any platform or service may be 
measured by a number of attributes and achieve¬ 
ments, such as: fast provision, prompt restora¬ 
tion, flexibility to meet customers’ requirements, 
quality of service etc. In the case of MRIS, an 
additional and important aspect relates to the 
network’s flexibility in terminating high volumes 
of calls. In this latter respect, MRIS call volumes 
are impressive: 


t BT Products and Services 
* BT Worldwide Networks 



|-GUIDELINES 

SPEAKING CLOCK 


r 


CALLSTREAM ENHANCEO 
MANAGED SERVICE 


MANAGED 

RECORDED 

INFORMATION 

SERVICES 


1936 1956 


1986 1991 


Q since its launch in 1987, the basic managed 
platform, based on recorded announcement 
centre equipment, has terminated over 67 million 
revenue-earning calls, 

© since May 1990, the recorded information 
distribution equipement (RIDE) systems (in¬ 
itially digital main switching unit (DMSU) RIDE 
and later derived services network (DSN) RIDE) 
have terminated over 65 million calls to the Lon¬ 
don code change announcements (non revenue 
earning). 

© since its launch to customers in January 1991, 
the DSN RIDE system has terminated over 
5 million revenue-earning calls. 

Detailed below are examples that epitomise the 
success of the MRIS platform. While this success 
is partially attributable to the network and technol¬ 
ogy used within MRIS, it is the people and teams 
behind the technology that ensure success. As has 
been indicated in previous articles, MRIS is sup¬ 
ported by small teams of experts across a number 
of functions in BT: product line, Worldwide Net¬ 
works (WN) Technical and Project Management, 
BT Laboratories, Network Operations and Busi¬ 
ness Communications. It is the dedication and 
drive of these teams that enable MRIS to deliver 
the products and features customers require. 


Figure 1 

Growth of managed 
recorded information 
services 


SERVICE PROVISION 

MRIS is a pre-installed network of terminating 
equipment. Consequently, provisioning time- 
scales are not restricted by difficulties associated 
with installation of customer lines. Although 
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standard provisioning lead times are applied to 
the product, there are occasions when customers, 
or indeed Worldwide Networks, require service 
in considerably shorter time-scales. With the co¬ 
operation of the DSN data management team in 
Oswestry, service can and has been provided in 
hours, rather than days. 

Gulf War Crises 

At the outbreak of hostilities in the Gulf, the 
Navy and the Royal Air Force identified a need 
to provide information and contact telephone 
numbers to relatives of personnel serving in the 
Gulf. Within 24 hours of the request, an 0345 
service was provided on DSN RIDE, with BT 
staff at the central operations unit (COU) recor¬ 
ding the announcements. 

BT International required a means of provid¬ 
ing UK customers with up-to-date information 
on access availability to countries in the Gulf 
region. They were provided with a remote update 
service on DSN RIDE, thus allowing customer 
announcements to reflect the volatile situation. 

Scarborough Exchange Fire 

As the scale of network disruption resulting from 
the Scarborough exchange fire became apparent, 
a need to keep calling customers informed of 
access difficulties to certain number ranges was 
identified. At 03.00 hours, the network manage¬ 
ment centre (NMC), Oswestry, contacted the 
Head of MRIS Operations to explore the possi¬ 
bility of providing announcements on the DSN 
RIDE network. A scheme was devised to retrans¬ 
late the affected national number groups (NNGs) 
at all DMSUs to an 0800 number, routing to the 
DSN RIDE. By 07.30 hours, through cooperation 
at the NMC, network operations units and the 
national announcement centre (NAC), customers 
calling the affected NNGs received an informa¬ 
tion message from the DSN RIDE. This an¬ 
nouncement was updated as service was restored. 

As a result of this incident, a permanent ser¬ 
vice has been established allowing the NMC to 
redirect calls to an information message in the 
event of a network problem. 

Fast-Track Services 

Fast-track services have been established to en¬ 
able BT to react to a customer’s request for 
immediate service; for example, television com¬ 
panies reacting to an unplanned major event. A 
number of broadcast and televote services have 
been installed on DSN RIDE with remote-update 
facilities and full availability of on-line statistics. 
The televote services allow for 2 to 6 voting 
options. All 0891 access numbers are preinstalled 
in the DSN; therefore, on request, the Callstream 
customer service centre can immediately provide 
the customer with details of access numbers, 
remote update details and on-line statistic access. 
Once the customer has finished with the service, 
the remote-update and statistics codes and per¬ 


sonal identification numbers (PINs) are changed, 
ready for the next customer request. 

FLEXIBLE SOLUTIONS 
Dial-Up Live Feed 

As part of the broadcast product, the ability for 
customers to provide live commentary services 
over the PSTN network provides a fast and flex¬ 
ible solution. Traditionally, provision of live 
commentaries has involved the ordering and in¬ 
stallation of private wires or outside-broadcast 
facilities, which can be both expensive and in¬ 
flexible, particularly for short one-off events. 
The dial-up live-feed service is a simple solution, 
with access to equipment at the NAC from any 
PSTN telephone via an 0800 number. Commen¬ 
taries are then transmitted from the NAC around 
the RIDE network. Services have been provided 
for the Cheltenham Gold Cup and the 1992 Bud¬ 
get commentary. 

Interactive Services 

A trial of interactive services has involved close 
cooperation with a major home-shopping com¬ 
pany, to develop a generic BT product that is 
efficient and cost effective to maintain and con¬ 
figure while being flexible enough to meet cus¬ 
tomers’ requirements. BT Laboratories has 
developed a generic application that can be in¬ 
stalled and configured by Network Operations, 
and will have a full product launch later in 1992. 
Although running as a trial, the service has been 
fully operational, with the customer offering in¬ 
formation services, with name/address capture. 
Customer satisfaction with the service is high 
with generated revenue double that forecast at the 
start of the trial. 

RIDE APPLICATIONS 

As described in earlier articles, the RIDE system 
was developed to meet a market need for high- 
call-volume events such as media televotes, and 
medium-call-volume, but long-call-holding dur¬ 
ation events such as sports commentaries. Cur¬ 
rently, all such services operate on the DSN 
RIDE network. However, a significant increase 
in terminating capacity will become available 
with the upgrade of DMSU RIDEs. 

The market demand for televote campaigns 
has developed significantly with the successes 
achieved by events operated on MRIS, particu¬ 
larly due to the ability to provide immediate 
access to on-line statistics within the time span 
of a television programme. Detailed below are 
just some of the campaigns that have operated on 
RIDE: 

• 1991 British entry for Song for Europe (BBC) 
500 000 votes (in 2 hours); 

• 1991 Going Live final (BBC) 200 000 votes 
(in 30 minutes); 

(& weekly TV video vote (BBC) 30 000 votes (in 
5 minutes); and 
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® Racing and Test Match commentaries 150 000 
minutes of calls per week. 

The call stimulation of major television events 
could cause problems within the PSTN network 
if not correctly controlled. Therefore, there is 
close cooperation between the NAC and NMC 
which allows traffic-management staff to preplan 
for such events and establish appropriate controls 
within the network to protect other users, while 
maximising call completions for the campaign. 

NETWORK UTILISATION OF MRIS 
London Code Change 

As described earlier, the major network use of the 
MRIS platform has been to provide an¬ 
nouncements to support the London code 
change. The use of DMSU RIDE and latterly 
DSN RIDE provides a cost effective and efficient 
means of terminating extremely large volumes of 
calls on a small number of announcements. Since 
the change of the London dialling codes in May 
1990, over 65 million calls have been terminated. 
In December 1991, 18 months after the change¬ 
over, an average of 700 000 calls per week were 
still being routed to the announcement. 

It is planned that the DMSU RIDE will pro¬ 
vide announcements to support the national code 
change. 

PSTN Changed Number Announcements 

The use of MRIS to provide network changed- 
number announcement services originated from 
a request for assistance from WN Scotland. The 
zone required additional announcement capacity, 
which would have resulted in the purchase of 
additional equipment. However, it was identified 
that capacity existed within MRIS, on first- 
generation answering equipment, that would sat¬ 
isfy the requirements and provide a high-quality 
start-at-the-beginning announcement. Currently, 
100 announcements are provided at Glasgow 
recorded announcement centre for this purpose, 
terminating 25 000 calls per day. Although using 
some network capacity, the resultant savings in 
capital expenditure are significant. An initiative 
to provide access to other zones is currently being 
pursued within WN (South). 

IMMEDIATE FUTURE OF MRIS 

In the immediate future, developments are 
planned for the MRIS product portfolio, each of 
which will enhance the previous product offer¬ 
ing. When complete, all currently identified mar¬ 
ket requirements will have been fulfilled 1 . It is 
intended to complete this programme in three 
discrete phases : 

Phase 1 

The introduction of BT call management on man¬ 
aged services will remove the need for service 
providers to define the line capacity required to 
meet caller demand. 


Phase 2 

The following features will be added to the Man¬ 
aged Service portfolio: 

© real-time statistics, 

© fast-track service, 

@ interaction with the calling customer, 

® information capture, and 
Q live service. 

Within this phase the following features will 
be added to the Callstream Enhanced Managed 
Service: 

0 extra capacity will be installed to cater for the 
increasing popularity of televotes, 

0 high-calling-rate information-capture fa¬ 
cilities will be made available, and 
© interaction with calling customers will be 
made possible. 

Phase 3 

This phase sees the merging of all the current 
MRIS product offerings into a single enhanced 
managed service and will be achieved by ex¬ 
tending the MRIS platform to encompass PSTN 
codes in addition to LinkLine and Callstream; 
and by moving from sole delivery of informa¬ 
tion by speech to using other media such as 
facsimile. 

POSSIBILITIES FOR FUTURE MRIS 
GROWTH 

In the future, there are many areas to explore and 
challenges to be met on MRIS. Novelty value 
may well lead the take up of new applications, 
but it is convenience and value for money that are 
essential in sustaining successful services. 

Fulfilment of the currently identified market 
requirements will secure the short- and medium- 
term future of MRIS. However, for MRIS to 
survive in the longer term, three key areas will 
have to develop further to meet the growing 
expectations of both the callers to, and providers 
of, information services: 

© technology, 

O information, and 
O service. 

Although the development of these three areas 
can progress independently, a major break¬ 
through will only happen when the technological 
advancements and commercial needs coincide. 

Technology 

The technology associated with MRIS will ad¬ 
vance in ever shortening time periods. The in¬ 
creased functionality, together with the reduction 
of technology costs (in real terms), will influence 
the expansion of MRIS and bring profitable new 
applications to the fore. It is evident from recent 
experience that there are two key enablers in the 
automated voice arena—voice recognition and 
computing power. 
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Given increased vocabulary on voice services 
equipment (VSE) 2 together with continuous 
word and number recognition, services run on 
MRIS will become more sophisticated and 
eventually a point will be reached when callers 
will not necessarily realise they are talking to a 
machine. It is conceivable that caller verification 
and voice security will be developed and, if 
loaded onto the MRIS platform, services requir¬ 
ing, say, closed user groups can be operated. 

Improvements are needed in computing 
power to host programs running complex ser¬ 
vices, storing announcements/information for 
callers and capturing their responses. One way of 
realising the required computing power is to pro¬ 
vide data links between VSEs and mainframe 
computers. This method opens up yet another 
rich new source of information and, sub¬ 
sequently, services. 

As MRIS technology develops, other forms of 
information storage and interaction will be 
possible: 

® The convergence of telecommunications and 
computing means that callers to MRIS could 
download, via ISDN for example, information in 
a data format. 

© The telecommunications industry is entering 
the videophone age, and a future MRIS could be 
used to provide visual information to callers, 
everything from dial-a-film to an online picture 
library. 

Information 

With the exception of the speaking clock and BT 
network announcements, the basic philosophy of 
BT MRIS has been defined. The information pro¬ 
vided for callers on the MRIS platform is always 
created by service providers, and it is BT’s respon¬ 
sibility to continue providing flexible and conveni¬ 
ent methods for delivery and updating of services. 
This is true for any information media from voice, 
through facsimile, to video. 

Service 

A dichotomy will arise as the MRIS technology 
becomes ever more complex while the need re¬ 
mains to keep the service as simple as possible for 
service providers and calling customers to use. It 
is therefore essential that mechanisms are provided 
to segregate the service management element from 
the supporting engineering platform. Progressive 
developments in this area will lead to remote ser¬ 
vice creation by service providers . 

In a world where consumers are becoming 
more sophisticated and the demand for informa¬ 
tion seems insatiable, services will have to com¬ 
bine to give a multi-media package of services. An 
embryo of this can be seen in demonstration ser¬ 
vices where, for example, callers can first listen to 
weather information and then, in the same call, 
request a detailed picture by facsimile. 

Other potential MRIS services and features 
are: 


• unattended message taking and forwarding, 

# voice-controlled interaction, 

© network voice call guidance, and 
® outgoing service. 

CONCLUSION 

MRIS is well placed to meet BT’s requirements 
to provide high-quality information to callers, 
whether for network reasons or as a value-added 
product for customers. The successes so far and 
the view of the future given in this article give a 
flavour of the potential for MRIS. 

To look forward 50 years and predict what 
MRIS will look like is not possible, even after 
using one of Callstream’s recorded horoscope 
services. One certainty is that ‘recorded’ will be 
too restrictive with the introduction of multi- 
media services such as facsimile and data. Per¬ 
haps in the year 2042, the Journal will comprise 
articles covering ‘Managed Information Ser¬ 
vices—Virtual Reality and Beyond’. 
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BT Demonstrates Videophone 

BT demonstrated at the Ideal Home Exhibition a prototype 
videophone for use in the home. The telephone, which will cost 
less than £500 and is expected to be available later this year, 
allows customers to see as well as hear the person on the line. 

The videophone will form part of a portfolio of videocom¬ 
munications products from BT, which at present includes video- 
conferencing and will in future comprise desk-top 
videoconferencing, digital videophones, and personal computer- 
based multimedia equipment. 

Easy to use, the new telephone does not require a special 
line—it simply plugs into a standard telephone socket. To make 
a call, a customer dials the telephone number in the normal way. 


The videophone has a small camera and a three-inch colour 
screen which are mounted on a flap that can be folded away. 
Privacy is assured by the press of a button or by lowering the 
flap. 

Designed and manufactured by British company GEC-Mar- 
coni, the telephone is currently undergoing extensive quality and 
reliability tests. 

BT has long recognised the benefits videotelephony can bring 
to customers and has made important inroads into the business 
market. However, the true worth of videocommunications will 
only be fully recognised when it becomes available to all custo¬ 
mers. 


Fax to the Future 

BT has launched a new Group 4 fax machine that can send one 
page of A4 in as little as three seconds and prints out desktop- 
published quality documents. 

The plain paper CF2000 is the newest addition to BT’s range 
of specialist products for use on the integrated services digital 
network (ISDN). 

Group 4 is the newest and most advanced fax mode. It uses 
the digital communications networks developing throughout the 
world’s business communities. In the UK, BT’s ISDN is avail¬ 
able in all key commercial centres. 

In Group 4 mode, transmission is far quicker than a Group 3 
machine, reducing the time and cost of telephone charges: one 


page of A4 can be transmitted in 3 seconds compared with a 
typical 13 seconds in Group 3 mode. (When communicating with 
a Group 3 machine, the CF2000 reverts automatically to Group 
3 mode.) 

The CF2000 will be of particular benefit to businesses sending 
faxes internationally and those sending fine-detailed documents 
such as construction plans and engineering designs. Interna¬ 
tional call time is the most costly and so it is here that the CF2000 
can offer the greatest savings. Furthermore, detailed documents 
can now be transmitted in better quality than a photocopy. This 
could well revolutionise working practice in industries such as 
architectuure, engineering and design. 


Channel 4 Backs World’s Most Advanced Digital Network from B r 


Channel 4 has backed BT’s commitment to broadcasting by 
signing a £50M contract over 10 years to take the world’s most 
advanced digital TV network. 

The new BT managed network is expected to lead to more 
flexible scheduling in commercials from Channel 4, who will be 
able to broadcast different advertisements simultaneously in six 
regional TV areas. The commercials will be transmitted direct 
from Channel 4 headquarters in London. From 1 January 1993, 
Channel 4 will sell and play out its own advertisements. 

Digital technology gives the network greater flexibility and 
speed. Channel 4 can utilise the new technology and BT’s 
network management capability to achieve cost-effective re¬ 
gional scheduling while enhancing its advertising offer with a 
more geographically targeted option. It will enable Channel 4 to 
compete more aggressively with ITV franchise holders for re¬ 
gional advertising revenue next year. 

BT has married computer and network technology to create 
management systems for round-the-clock monitoring with built- 
in performance guarantees. Channel 4 will have direct monitor¬ 
ing access for added control. 

The network is designed for 10 seconds’ restoration, and BT 
is guaranteeing 30 seconds for most of the transmitter sites. The 
digital network, operational from January 1993, is seen as fun¬ 


damental to the success of the channel’s regional network, and 
gives Channel 4 a technological lead over other commercial 
broadcasters. 

The digital network breaks new ground in broadcasting and 
confirms BT’s leading role in developing complete solutions for 
its customers. 

The new network will improve quality and consistency of 
pictures transmitted to all parts of the UK. The core network and 
programme contribution material carried on it will operate in¬ 
itially at 140 Mbit/s, while sound, vision and associated signals 
carrying the output of the channel will be coded and delivered 
to transmitters at 34 Mbit/s. 

BT’s digital technology is a response to the demand for even 
higher-quality stereo sound and video transmission in today’s 24 
hour broadcast environment. BT has also built in new levels of 
network reliability and an upgrade path to wide-screen TV. 

Steve Maine, Director of Visual and Broadcast Services, said, 
‘By committing major investment to the development of digital 
network technology, BT is driving a broadcasting equivalent of 
the “Big Bang” which will revolutionise British TV in the 1990s. 

‘Our work with Channel 4 and our ability to innovate is a result 
of the understanding we have built up over 56 years working in 
television broadcasting.’ 
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Boole Review 


Common-Channel Signalling 
R. J. Manterfield. 

Peter Peregrinus. xxxiii+221 pp. £38 00. 

ISBN 0 86341 240 8. 

This book identifies signalling as a key element, alongside 
switching and transmission, in a modern telephone network. The 
book briefly traces the evolution of signalling from the relatively 
simple systems of the past up to the sophisticated common-chan¬ 
nel signalling systems of today. 

The author has concentrated on giving a comprehensive in¬ 
troduction into the principles of common-channel signalling 
rather than describing any specific implementations in detail. 
This has resulted in an extremely readable book that provides an 
excellent introduction into this highly complex subject. The 
book provides sufficient breadth and depth to prepare the reader 
for the highly detailed and complex signalling specifications and 
international standards recommendations. 

The book is well structured and introduces the reader to the 
subject in a logical step-by-step manner. It first describes the 
layered architecture of modem signalling systems and then 


describes each layer in turn. The author makes very good use of 
examples throughout the text to bring clarity to this difficult 
subject. Also the provision of a summary at the end of each 
chapter is particularly useful. 

The book identifies the inseparable relationship beteen com¬ 
mon-channel signalling and the central processor of digital 
stored-program control exchanges. Also identified is the conver¬ 
gence between the techniques used for signalling between ex¬ 
changes within the main network and those used for signalling 
between the network and customer equipment. 

The book makes little mention of the extensive use that is 
being made of common-channel signalling on digital PBXs and 
within private digital networks. Coverage of this would have 
been particularly appropriate in the context of PBX access to the 
integrated services digital network in the chapter on the Digital 
Subscriber Switching System No. 1. 

The book contains a wealth of information and will provide 
an excellent reference for all those involved in telecommunica¬ 
tions. 

A. Hiett 


Notes and Comments 


JOURNAL DISTRIBUTION—NOTIFICATION OF 
CHANGES OF ADDRESS 

IBTE Members and Journal subscribers who change their ad¬ 
dress should ensure that they notify the Journal office on the 
address-label slip provided with every copy of the Journal. 

All enquiries related to distribution of the Journal should be 
directed to the IBTE Administration Office (see below). 

CONTRIBUTIONS TO THE JOURNAL 

Contributions of articles to the Journal are always welcome. 
Anyone who feels that he or she could contribute an article 


(either short or long) on a telecommunications engineering topic 
is invited to contact the Managing Editor at the address given 
below. Guidance notes for authors are available and these will 
be sent on request. 

BTE JOURNAL/IBTE ADMINISTRATION OFFICE 

All correspondence and enquiries relating to editorial matters 
(‘letters to the editor’, submissions of articles, requests for 
authors’ guidance notes etc.) and distribution of the Journal 
should be sent to: BTE Journal Editorial Office/IBTE Adminis¬ 
tration Office, Post Point G012, 2-12 Gresham Street, London 
EC2V 7AG. (Telephone: 071-356 8050. Fax: 071-356 7942.) 


THE INSTITUTION OF BRITISH TELECOMMUNICATIONS ENGINEERS 


ANNUAL GENERAL MEETING 

Great Western Royal Hotel, Praed Street, Paddington, London WC2 1HE 

3 June 1992, commencing at 17.30 
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AUXILIARY SWITCH 


For further information please call: 



Telspec Limited 

Lancaster Parker Rd, Rochester Airport, 
Rochester, Kent, England MEI 3QU 
Tel: (0634) 687133 

Fax: (0634) 684984 Tlx: 965617 TLSPC G 


The Advanced Digital Applications 
Processor is an advanced software 
controlled digital switch which 
provides intelligent flexible call 
routing, and switching functions 
in a variety of applications within 
Telecom networks. The Auxiliary 
Switch is a typical example. 

Some of the features are: 

® Wait-on-start 

© Broadcast 

® Mid-call-diversion 

© Events database 

® Allows reduction in 
VSE requirements 

• DDI call routing 

• Protocol conversion 


ADAPTEL COMMANDER 
BNTEtlFACE 

Use the ACI to write your own 
applications for the Adaptel. 










































Hi-Call has become 
the automatic 
choice for intelligent 
network services 

Not only in Europe: Hi-Call is now 
the premier voice services platform for 
intelligent network applications in ten 
countries worldwide. 

And no wonder, because the 
powerful new Hi-Call range provides 
friendly voice technology for every kind 
of information, telemarketing or 
enhanced network service. Whatever 
your voice service needs, Hi-Call offers 
the professional solution. 

Six interactive options on all lines. 
Capacity for up to 1,000 services on each 
30-line Hi-Call. Fast access to services 
via Direct Dial In and PSTN interfaces. 
Call diversion to live operators through 
ACDs, PABXs or Centrex exchanges. 
Host interface for database applications. 
All integrated on the Hi-Call platform by 
PDL, the world s leading applications 
language for voice services. 

For the full story, contact your 
nearest Telsis office. 


Telsis 


Bringing technology to life. 


TELSIS LIMITED, Barnes Wallis Road, Segensworth East, 
Fareham, Hampshire P015 5TT, England. 

Tel: + 44(0) 489 885877, Fax: + 44(0) 489 885826 


TELSIS GmbH, Rosslerstrasse 88, 

6100 Darmstadt, Germany. 

Tel: + 49 6151 82845, Fax: + 49 6151 896235 


TELSIS PTY LTD, 119 Willoughby Road, 
Crows Nest, NSW 2065, Australia. 

Tel: + 61 2 956 3802/3, Fax: + 61 2 439 2143 
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